Hemant,
Your logic escapes me. Old implementations are *old*
and will continue to do whatever their code does.
No words in 2462bis or 2462ter or anywhere can change
that. I think your proposal is a no-op.
Brian
On 2007-06-22 15:05, Hemant Singh (shemant) wrote:
Hi Tatuya,
Thanks for the quick review of section 5 in our new I-D. Your reading
of section 5 is correct - we have proposed both new and old
implementations to always perform DAD for any unicast address. You are
also correct that the gross change we have proposed over 2462bis is that
old implementations MUST also not skip DAD. We stress about old
implementations because if older implementations that are already
deployed continue to be deployed for say, the next 5-10 years, that's
not good. A software upgrade to older implementation is certainly
possible.
We have given a solid reason for our case - it's presented in Section 2,
bullet 4 of our I-D. Please see if our reasoning is solid enough to
convince IETF.
Thanks.
Hemant
-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 10:40 PM
To: Hemant Singh (shemant)
Cc: ipv6@ietf.org; [EMAIL PROTECTED]; Wes Beebee (wbeebee); Ralph
Droms (rdroms)
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changes suggested to 2462bis-08
At Thu, 21 Jun 2007 12:31:58 -0400,
"Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
Please see section 5 of our I-D for a proposed change to 2462bis-08 -
we hear this I-D is in Editor's queue and any changes to it must be
given ASAP.
(with the document editor hat of 2462bis on)
From a quick look at Section 5 (and that section only), the key point of
the proposed change is:
skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do
it (but existing ones still performing the optimization will not be
accused of non-conformance)
to
skipping DAD is completely prohibited, and all new/old
implementations MUST always perform DAD for any address.
Is that correct?
If so, I suspect it's too controversial to merge in 2462bis at this
stage. This part was indeed a result of very heated discussions, and
even though (I believe) we all knew that simply prohibiting it without
exception was a cleaner resolution, we failed to reach a clear consensus
on it; hence the current text as a sort of compromise.
If your new draft could now perfectly convince those who opposed to
prohibiting the DAD optimization before 2462bis goes to the AUTH48
state, I, for one, would be happy to include it to the final version of
2462bis. But I cannot be that optimistic.
In any event, I don't think changing the phrase matters much; we already
clearly state new implementations MUST NOT skip DAD, so the change only
affects existing implementations. I suspect a certain amount of
existing implementations that skip DAD as specified in
RFC2462 will still keep the current behavior whatever the new 2462bis
RFC specifies. But they'll eventually be replaced with new
implementations, which, if conforming to 2462bis, won't perform DAD
skipping.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba
Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
