Re: [rfc2462bis issue 275] DAD text inconsistencies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rfc2462bis issue 275] DAD text inconsistencies



 In your previous mail you wrote:

   As you know, there have been many discussions on DAD, including
   
   - whether omitting/optimizing DAD is a good idea

=> IMHO this is the same thing, i.e., optimizing gives the same result
than omitting.

   - (if yes) in which case we can omit DAD
   - DAD vs DIID

=> the last one finished by a decision (DAD, not DIID). I asked the
WG chairs to clarify this point at a previous meeting, cf
http://www.ietf.org/proceedings/02jul/145.htm
look at "DAD vs. DIID Discussion -- Chairs", BTW slides are at
http://playground.sun.com/ipng/presentations/July2002/yokohama-dad-vs-diid.pdf

   - ...
   
   without getting any convergence (particularly about DAD
   omission/optimization or DIID), unfortunately.
   
   Having considered these points, possible resolutions *for rfc2462bis*
   that I can think of are:
   
   1. harden the requirement: Each individual unicast address MUST be
      tested for uniqueness.  No MAY for omitting the rule (i.e., remove
      it).  We can use SHOULD instead of MUST if we need compromise.
   
=> I vote for this in the context of RFC 2462bis.
   
   I personally prefer option 1, because this makes the intention very
   clear, avoiding further similar discussions and waste of energy.
   "MUST" may be too strong for compatibility with existing
   implementations, and if so, we can use "SHOULD".  (And this does even
   not conflict with the proposed "optimistic DAD")
   
=> I agree.

Thanks

Francis.Dupont@enst-bretagne.fr

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.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.