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]
--------------------------------------------------------------------
