Subject: RE: On-link issues, draft-wbeebee, 2461bis

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 23 Oct 2007 11:57:38 -0400

6man folks,

Friendly reminder. Could folks please review the first two drafts in the
list of three below. We would like to get the two drafts on the 6man WG
agenda for the 70th IETF meeting.

Thanks.

Kind Regards.

Hemant

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Monday, September 10, 2007 10:23 AM
To: Jari Arkko
Cc: Thomas Narten; IETF IPv6 Mailing List; Hesham Soliman
Subject: RE: On-link issues, draft-wbeebee, 2461bis

Hi Jari,

As per your request below, we broke up the original I-D into separate
drafts.  We decided to make three drafts rather than the two you
suggested so that the third can be incorporated into any new ND
documents at some future time when such changes are allowed.

The URLs to the new drafts follow:

1)
http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d
etermination-00.txt

2)
http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-prob
lems-00.txt

3) http://www.ietf.org/internet-drafts/draft-wbeebee-nd-updates-00.txt

Please review the drafts in the order of precedence listed (reviewing #3
quickly is of lesser importance than reviewing #1 and #2).  Note that #1
and #3 are on the standards track, whereas #2 is informational.  

Thanks.

Hemant & Wes. 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Tuesday, August 21, 2007 7:03 AM
To: Hemant Singh (shemant)
Cc: Hesham Soliman; Wes Beebee (wbeebee); Thomas Narten; IETF IPv6
Mailing List
Subject: On-link issues, draft-wbeebee, 2461bis

Hemant,

I have reviewed your draft and the discussion on the IPv6 list.

Its easy to believe that there are implementations out there that get
things wrong. I also agree with the general technical direction about
DAd and being specific about where ND on-link assumptions and prefixes
can come from. And we should value implementation experience and
document it where it can potentially help future implementers.

However, we already had a discussion about whether the 2462bis document
should change. The WG believes they have gotten the current requirements
right, and I can't really blame them for that. Please note that once
2462bis is an RFC, IETF's official recommendation is to do exactly what
you want to happen. Those implementations that pay attention to such
things will change (if they need to). It is unfortunate that earlier
RFCs and some implementations operated differently. But it is something
that issuing a new RFC cannot alone fix; we just have to live with that.
I would also note that the DAD process as a whole is not bullet proof.
Dropped packets, network partition, etc. can still cause duplicated
addresses to occur. The engineering is to get the probability of that
happening reasonably low, and I think we are there.

You also suggested that 2461bis be changed to clarify the on/off-link
rules. I thought that most of your clarified rules were good, though I
did not perform a detailed review so there may still be issues. I note
that others had question marks on some of them. In any case, my big
question is to what extent you are (a) making an implementation error
less likely by emphasizing and reformulating rules that 2461bis already
has or (b) making some actual new, tighter rules. I think most of it
falls under category (a). Is there some that are in (b)?

However, the amount of new text goes beyond what we can put in under
AUTH48. Given that the group does not seem to unanimously believe that
the rules are missing from 2461bis, I feel reluctant to go through the
approval process once more.
It is more important to have a standard than to achieve perfection.

However, I would like to make sure that the implementation guidance is
not lost. And it may even be that after a discussion we realize that the
on-link rules need further work. Its completely possible that we have to
clarify some part of ND even after 2461bis has been published; the
maintenance WG has been created in order to deal with issues like that.

Here's what I would suggest:

1) We proceed with 2461bis publication.

2) We proceed with 2462bis publication.

3) You write one document that collects the implementation
guidance/clarified rules regarding on/off link behaviour, and offer it
for the new
IPv6 maintenance WG.

4) You write another document that collects other implementation
experience, and also offer it to the same WG.

Jari

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

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