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

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Aug 2007 14:03:24 +0300

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 21 Aug 2007 11:35:53 -0400

Jari,

Wrt to this point you raised snipped in quotes below, please see our
response:

"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)?"
 
In the -02 version of our I-D, we are not making any new rule over what
has not been already specified in 2461bis or 2462bis. This is subject to
everyone agreeing with our interpretation of 2461bis. So yes, I believe
our rules fall only under (a) above. As for question marks on any text
in our I-D, so far only Jinmei and Vlad Yasevitch have reviewed our I-D.
Vlad reviewed the complete -01 version of our I-D. We closed all issues
in -01 with him in the -02 version - he can correct me if I am mistaken.
Jinmei reviewed only the portion of our -00 and/or -01 I-D that proposed
changes to 2462bis. We have also closed any question marks with him on
his review - he wanted us to back off forcing older host implementations
to change for skipping DAD - we did back off.

As to the extent of our clarification, I don't think the IPv6 community
or the RFC's were clear on how to specify off-link in RA. We found
passing references to off-link behavior in one paragraph of a general
section 3.1 in 2461bis - we mention this paragraph in section 2.1 of our
I-D. Then we found one paragraph in section 6.3.4 of 2462bis where
off-link behavior was implied. Since off-link has been specified by
2461bis as the opposite of on-link, we are saying even on-link is not
clearly specified in some cases. Therefore, it's not just stricter
language and reformatting of rules that is the output of our I-D.
2461bis does not have ANY clear rules to specify off-link - it's just
text buried in some paragraph that one has to interpret as off-link
behavior. I have gone into enough details in emails as to why specifying
on- vs. off-link is key to ND because that affects whether a host
performs address resolution or send traffic to default router. Incorrect
host behavior leads to loosing network connectivity in an aggregation
router network.

As per your guideline, here is our plan moving forward for the two
documents. We are basically breaking up our I-D into two new documents
where none of the two new documents will include sections 5 and 6 from
our existing I-D - these section relate to proposed changes to 2461bis
and 2462bis respectively.

1. We will put together a document that collects the implementation
guidance/clarified rules regarding on/off link behavior - this document
will include sections 2-4 of our current I-D. This document makes sense
to be on Standards Track or be a BCP.

2. We will put together a second document that collects other
implementation experience. This document will follow a format as
specified in section 7 of our I-D. This document makes sense to be on
Informational track. Anyone is welcome to send us logs of key ND bugs to
add to this document. 

Best Regards.

Hemant

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

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.

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