Francis, is the following question equivalent to what you are asking ? Does the Home Agent do a Neighbor Advertisement proxy for link-local addresses of mobile nodes which are away ?
Related question, does MIPv6 allow link-local addresses as Home Addresses ? The mobile node, when it returns may use a different interface to connect to the home network. The Home Agent does not know how many interfaces the mobile device has, nor should it. Subrata -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Francis Dupont Sent: Sunday, May 26, 2002 7:03 AM To: [EMAIL PROTECTED] Subject: DAD or DIIDD In the Mobile IPv6, the home agent provides a neighbor discovery proxy service (RFC 2461 7.2.8: basically it answers to Neighbor Solicitations as for one of its addresses but with a short delay (collision avoidance) and with always the Override flag set to zero). So if someone tries to perform a DAD over one of these proxied addresses, the DAD should fail. But what happens if the DAD is performed for the associated link-local address? To summary the debate in the mobile-ip list, the question is "the mobile node returning at home may or may not use the link-local address which is associated to its home address, i.e. shares the interface ID?" This raises a question I summarize by DAD or DIIDD (Duplicated Address Detection of Duplicated Interface ID Detection). The two references are subtilely incoherent: RFC 2373 (and last I-D draft-ietf-ipngwg-addr-arch-v3-07.txt): 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. ... In many cases an interface's identifier will be the same as that interface's link-layer address. RFC 2462 4. PROTOCOL OVERVIEW For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfig, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier need not be tested individually. In contrast, all addresses obtained manually or via stateful address autoconfiguration should be tested for uniqueness individually. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. and in 5.4. Duplicate Address Detection ... Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases: - Duplicate Address Detection MUST NOT be performed on anycast addresses. - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. We have two solutions to solve this issue: - the first one is to affirm that DAD is not a DIIDD: * removal of the uniqueness of IIDs in address architecture (only link-local addresses must be unique) * removal of the "same interface identifier" considerations in RFC 2462 * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast addresses Implementation changes are: - for stateless configuration or stateless configuration-like mechanisms the only difference is the removal of the MAY in 5.4. - for other mechanisms the DAD detection for the address itself doesn't change but this choice makes clear the associated link-local address should not be object of a DAD. This is the simpler fix but IMHO not the best. - the other option is to change the DAD in a DIIDD: * no change in address architecture (cf an Erik Nordmark's argument about architectural purity) * the "a set addresses formed from the same interface identifier" is in totally abusive way applied even for a set of one address so DAD for the associated link-local address becomes mandatory and DAD for the address itself MAY be skipped. Implementation changes are: - for stateless configuration: no difference - for stateless configuration-like mechanisms: the rule to apply is the same than for stateless configuration (i.e. clarification) - for other mechanisms the DAD for the associated link-local address is mandatory but the DAD for the address itself becomes optional (or will become optional in X years for compatibility). This choice has a real impact on router implementations, I'd like to get a feed-back from router vendors (is it acceptable?) Regards [EMAIL PROTECTED] PS: I believe we should solve this issue before the next IETF meeting! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
