Re: [NDP] Router autoconfiguration with RS/RA
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NDP] Router autoconfiguration with RS/RA
2008/6/6 Alexandru Petrescu <alexandru.petrescu at gmail.com>:
> Hemant Singh (shemant) wrote:
>> Silviu,
>>
>> A router can receive an RA on the router's upstream
>
> Yes it can. It uses it to report whether some things went wrong, log
> stuff, but don't act.
>
>> and use this RA to autoconfigure the ipv6 address on interface(s) of
>> the router.
>
> Usually no, it can not. A particular case of a Mobile Router away from
> home can auto-configure an address on its egress interface with
> stateless autoconf. But a non-mobile router (not implementing rfc3963)
> can't and it shouldn't.
>
> A router is something that forwards packets. A linux router can't
> auto-configure an address once one sets the forwarding=1. A Cisco
> router I have doubts, but it doesn't mean it follows rfc.
a router can very well have an interface configured in host mode where
it uses normal host configuration mechanisms. it obviously can't
advertise any learnt information back out the same interface. I don't
see any reason why it couldn't also do forwarding on this interface.
router/host mode is a per interface property.
and has been said before the RS/RA mechanism for router
discovery/prefix discovery does not support prefix delegation. of
course you can invent a new protocol using RS/RA messages to do it,
but I haven't seen any convincing reason why we should. note that the
DHCP PD was triggered by a draft proposing using ICMP for PD. we
suggested using DHCP instead, since one eventually would have
reinvented lots of the DHCP machinery to make it work.
/ot
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.