On 05/27/10 09:28 PM, Reddy, Joseph wrote:
Hi ND authors, I have a question on the choice of source address for the NS packets When a new address is to be configured, the draft requires the host to send NS with with the IPv6 source address set to this address and to also include ( must ) the SLLA option Does this not cause a violation of the address scoping rules ( since the destination address is a link local address derived from the RA while the source is a global, assuming we want to register a global address ) ?
There is no prohibition of combining different address scopes in IPv6. RFC 3484 tries to avoid such combinations when the stack needs to select a source/destination path for an application, but that is a different matter. In the 6lowpan-nd case the sender and receiver are neighbors, hence the RFC 3484 considerations don't apply.
Is there a reason why the unspecified address is not used for the source ( and include the address in the ARO option ) like in classic ND ?
RFC 4861 only allows the unspecified source address in NS message for the purposes of DAD, which is integral to using multicast packets for DAD.
Is there a reason to use the unspecified address in some new way?
If this is because you want to include the SLLA option, note that this is not really necessary since the link layer source address can be deduced by the router from the L2 headers
I think that would be architecturally unsound, because we want IP to be able to run over a rich set of datalink technologies, and over time we have seen datalinks that do odd things to the addresses in the datalink headers. This is now new with IPv6 and ND; arp carries the hardware addresses in the ARP header, even though they are also in the Ethernet header that encapsulates the ARP header. This seemed to have served us well as the Internet has evolved.
Also, if a host wants to register with multiple routers, it seems that each of the routers will end up doing the multihop DaD on the address. This will waste bandwidth ( as well as reduce battery life of host since the process will be much longer ). Instead, it will be useful to allow the host to differentiate between the intial address registration ( when DaD is needed ) and subsequent ones. One way to do this would be to use the unspecified source address during initial registration followed by the actual address for subsequent ones.
A 6LR can trivially tell whether or not it is a re-registration from the host - whether or not it already has a Neighbor Cache entry. If the optional multihop DAD is used, this means that the 6LR can respond immediately to the host for a re-registration.
Erik _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
