Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt

From: [email-masked]
Date: Thu, 13 Nov 2003 00:59:45 +0200

Hi all,

> > 	but then, if we change it to MAY, what is the point in running DAD
> > 	process?  if you do not disable interface (or the address on the
> > 	interface) the owner of the same address will get confused,
> > 	peers of the address get confused, you will do bad things to the
> > 	original owner of the address.  
> >
> 
> I see disabling the interface and disabling the address on the interface
> as two separate actions.
> 
> So, I agree that the interface MAY be disabled.

Agreed. It is Duplicate ADDRESS Detection, so disabling the address is reasonable,
disabling the interface is probably too strong.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Nov 2003 20:03:59 +0900 (JST)

> disabling the interface is probably too strong.

	re-read the exact text, and i think the above makes sense.

	so proposed change: the last part should be changed to "the interface
	address SHOULD be disabled".  (add "address")

itojun

5.4.5.  When Duplicate Address Detection Fails

   A tentative address that is determined to be a duplicate as described
   above, MUST NOT be assigned to an interface and the node SHOULD log a
   system management error.  If the address is a link-local address
   formed from an interface identifier, the interface SHOULD be
   disabled.

---

From: "Chirayu Patel" <[email-masked]>
Date: Thu, 13 Nov 2003 17:00:15 +0530

On Thu, 13 Nov 2003 20:03:59 +0900 (JST), "Jun-ichiro itojun Hagino"
<[email-masked]> said:
>
> > Agreed. It is Duplicate ADDRESS Detection, so disabling the address
> > is reasonable, disabling the interface is probably too strong.
>
>       so proposed change: the last part should be changed to "the
>       interface address SHOULD be disabled".  (add "address")

Some explanatory text will be needed regarding the semantics of a
"disabled" address, and further actions. Points to be discussed
will include:

    1) How long should an address be disabled for - permanent, or timer
       based? A timer based disabling mechanism might be useful in case
       the user is not able to generate an IID, and wants to re-enable
       the address.

    2) If the disabled address is a static address, then how should
       the user be informed? This one should probably be documented in
       some API document, though I doubt if it is in the purview of an
       IETF document.

    3) Points raised by Thomas - recommendation for generation of new
       IID's, and frequency at which the retries (with new IID's)
       shall be done.

CP

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Nov 2003 15:12:12 +0200 (EET)

> 	address SHOULD be disabled".  (add "address")

If we say something to this effect (i.e., the address), I believe it 
should be a MUST.  There is really zero excuse to continue using an 
address if DAD fails.  On the other hand, there may be some reasons for 
continuing to use the interface.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings