Subject: [Gen-art] gen-art review of draft-ietf-ipv6-2461bis-09.txt

From: Scott W Brim <[email-masked]>
Date: Wed, 8 Nov 2006 07:52:08 -0800

I am the assigned Gen-ART reviewer for draft-ietf-ipv6-2461bis-09.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.  Please
resolve these comments along with any other Last Call comments you may
receive.

Summary statement: This draft is basically ready for publication, but
has nits that should be fixed before publication.

I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very important.
For the sake of new implementors I have a number of suggestions for
clarity.  Many of them have to do with the use of "SHOULD", since we
have been polishing up its use and advice to implementors.

I'll start with my protocol question:

  7.2.7 Anycast neighbor announcements
  
    - "Second, the Override flag in Neighbor Advertisements SHOULD be
      set to 0, so that when multiple advertisements are received, the
      first received advertisement is used rather than the most
      recently received advertisement."
  
    How does the Override flag work when you advertise an included
    prefix?  In this case, I'm advertising a single route to you with
    the Override flag off.  What if you already have a route to a
    larger prefix that includes it?  Do I punch a hole?  Am I
    discarded?  Is this documented?

OK, onward to non-protocol issues.  

3.0 protocol overview

  - Duplicate address detection

     "Duplicate Address Detection: How a node determines that an
     address it wishes to use is not already in use by another node."

    should be

     "Duplicate Address Detection: How a node determines whether or
     not an address it wishes to use is already in use by another
     node."
      
  - Router advertisement: the phrase "on-link determination" has not
    appeared before.  It should be explained.
    
4.1 router solicitation message

  - Source link-layer address

      "The link-layer address of the sender, if known.  MUST NOT be
      included if the Source Address is the unspecified address.
      Otherwise it SHOULD be included on link layers that have
      addresses."

    We've been tightening up "SHOULD"s recently.  RFC2119 says:
    
      SHOULD   This word, or the adjective "RECOMMENDED", mean that
      there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different
      course.
  
    In this draft, "otherwise ...  SHOULD" implies that there are
    situations in which the link layer address is known, and the
    source address is included, but the link layer address may be
    omitted.  RFC2119 says that deserves explanation.  As guidance to
    implementors, who are supposed to understand the full implications
    and carefully weigh them, when would this be appropriate?  For
    load balancing?  If so just say so.  For example down below in
    Router Advertisement Message, you say "A router MAY omit this
    option in order to enable inbound load sharing across multiple
    link-layer addresses."  Something like that would work here -- if
    nothing else add a pointer to text elsewhere.  

    There are more issues with SHOULDs not being thoroughly explained
    below.  I'm only listing the ones where I believe naive
    implementors might benefit from explanation.  

4.2 router advertisement

  - "Note: If neither M nor O flags are set this indicates that no
    information is available via DHCPv6."

    This means that the responding router always knows if DHCPv6 is
    definitely available or definitely not available.  Is there any
    possibility that the responding router might not know?  If so, how
    about changing the text to "is known to be available"?

  - "SHOULD be sent on links that have a variable MTU (as specified in
    the document that describes how to run IP over the particular link
    type).  MAY be sent on other links."

    Same comment on undocumented SHOULD.  How about changing it to
    "MUST be sent ...  (where specified ...)"?

4.3 neighbor solicitation

  - "Source link-layer address

      The link-layer address for the sender.  MUST NOT be included
      when the source IP address is the unspecified address.
      Otherwise, on link layers that have addresses this option MUST
      be included in multicast solicitations and SHOULD be included in
      unicast solicitations."

  Same thing about SHOULD.  If it SHOULD be included, under what
  conditions is it expected that it would not be?

4.4 Neighbor advertisement

  - Override Flag: "It SHOULD NOT be set in solicited advertisements
    for anycast addresses and in solicited proxy advertisements.  It
    SHOULD be set in other solicited advertisements and in unsolicited
    advertisements.

    SHOULD and SHOULD NOT without explanation.  Should these be MUSTs?

  - Target link-layer address: "When responding to a unicast Neighbor
    Solicitation this option SHOULD be included."

    SHOULD.  When would you not?

4.5 Redirect  

  - "It SHOULD be included (if known).

    SHOULD.  When would you not?

6.2.1 router config variables

  - AdvCurHopLimit

      "The value should be set to that current diameter of the
      Intern iset."

    s/that/the/

6.2.6 processing router solicitations

  - "If the router already has a Neighbor Cache entry for the
    solicitation's sender, the solicitation contains a Source
    Link-Layer Address option, and the received link-layer address
    differs from that already in the cache, the link-layer address
    SHOULD be updated in the appropriate Neighbor Cache entry, and its
    reachability state MUST also be set to STALE."

    Unelaborated SHOULD?

6.3.4 processing received router advertisements

  - In a paragraph that begins "After extracting information" ...

    "If the advertisement contains a Source Link-Layer Address option
    the link-layer address SHOULD be recorded in the Neighbor Cache
    entry for the router ..."

    This seems to be another unexplained SHOULD.

Setting the solicited flag ...

  - In 7.2.5, "An advertisement's Solicited flag should only be set if
    the advertisement is a response to a Neighbor Solicitation."

    However, in 7.2.6, "The Solicited flag MUST be set to zero, in
    order to avoid confusing the Neighbor Unreachability Detection
    algorithm."

    Is there a consistency problem here?

7.3.3 

  - "When a node needs to perform address resolution on a neighboring
    address, it creates an entry in the INCOMPLETE state and initiates
    address resolution as specified in Section 7.2.  If address
    resolution fails, the entry SHOULD be deleted, so that subsequent
    traffic to that neighbor invokes the next-hop determination
    procedure again."

    "SHOULD" again.  When would you not delete the entry?

  - "In the Target Address field: the address to which subsequent
    packets for the destination SHOULD be sent."

    That's talking about the recipient of the redirect.  It's not
    about the sender's behavior, so this SHOULD should not be
    capitalized.

8.3
  
  - "A host receiving a valid redirect SHOULD update its Destination
    Cache accordingly so that subsequent traffic goes to the specified
    target.  If no Destination Cache entry exists for the destination,
    an implementation SHOULD create such an entry."

    Another set of unsupported SHOULDs.  What if it doesn't?

9 Options

  - "Receivers MUST silently ignore any options they do not recognize
    and continue processing the message."

    I would add, as has been done in other WGs, that if a new option
    is so ignored by the receiver, protocol behavior MUST still
    continue as if the option had not been sent.  That is, processing
    of options is always backward compatible unless the option is
    declared as required.

(Did not check state machine)

Thanks.

swb

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 01:51:46 -0800

Thanks for the comments! Sorry for the late reply. Some comments inline 

 > have been polishing up its use and advice to implementors.

=> I appreciate the effort; as a general comment I should highlight that
the main reason for this work was to fix known bugs in the spec in a
backward compatible manner. Some or all of the changes of SHOULD to MUST
below might not be backward compatible.
As I'm sure you're aware, this spec has been widely implemented on all
major platforms and doing things in a non- backward compatible manner is
essentially prohibited.

Also, in general, having to describe situations where the SHOULD in the
spec can be avoided is a very difficult task and not really helpful
given the wide implementations of the spec. It really comes down to how
big a document you want :) I think given the description of keywords, if
something is strongly recommended but the protocol will not break if
it's not done, then it deserves a SHOULD. We don't need to explain all
or a subset of situations where avoiding that SHOULD makes sense.
Implementers who need to avoid the SHOULD already know why they need
that. Those who don't know, should follow the SHOULD. 

 >     prefix?  

=> I don't understand the question. The NA can only include a unicast
address. You can't include a prefix in the NA.

       In this case, I'm advertising a single route to you with

 >      not an address it wishes to use is already in use by another

=> ok.

 >     appeared before.  It should be explained.

=> We can add a reference here.

 >     nothing else add a pointer to text elsewhere.  

=> I'd appreciate comments on this from Thomas or Erik if they want to
add something here. Personally, while I appreciate the clarity
requirements, I think it's not necessary to always explain all possible
options for not following a SHOULD. From personal experience, I found
people using specs in ways that were not originally thought of, while
being legitimate (due to the use of MAYs and SHOULDs). So I'm inclined
to leave it as is but would like to hear if others see such ways of
clarification necessary.

 >     implementors might benefit from explanation.  

=> Ok, I think there are lots (most of the shoulds) in the draft that
are not explained as you describe above.

 >     possibility that the responding router might not know?  

=> I don't think so. It should always know.

 >     "MUST be sent ...  (where specified ...)"?

=> I have to give the same answer here. I don't think it's appropriate
to put MUST instead of the SHOULD above. The flexibility provided by the
SHOULD is important given the variety of link layers and *systems* (e.g.
3GPP, WiMAX ...etc) out there that define how IPv6 is used in their
environments. 
For the rest of the "SHOULD" comments I couldn't add or respond to your
comments any differently from my earlier comments. So I suggest we
handle all the "SHOULD" comments together at least initially. As I
mentioned earlier, in general, it's not a good idea to change SHOULDs to
MUSTs anywhere in the draft unless it's an obvious bug. 

 >       "The value should be set to that current diameter of the

=> ok.

 >     Is there a consistency problem here?

=> None whatsoever, the title of 7.2.6 is "Sending Unsolicited Neighbour
Advertisements", so naturally the Solicited flag must not be set in this
case.

 >     about the sender's behavior, so this SHOULD should not be

=> Hmm. That's true.

Hesham

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 22 Nov 2006 08:04:45 -0600

Hi, Hesham,

(dropping off several of the mailing lists from the CC line)

I'm not involved in this discussion, except that I'm also a Gen-ART 
reviewer, so wanted to respond to the discussion of SHOULDs in this 
thread...

It's not that specifications need to explain all possible reasons for not 
following a SHOULD - I agree with your statement that successful protocols 
are used in amazing ways - but I do think listing ONE possible reason as 
justification for a SHOULD instead of a MUST is reasonable.

In this case ("a draft name that ends in bis" ;-), saying that existing 
deployed implementations do something else might very well serve as that 
justification.

The problem that we are trying to avoid is loss of interoperability because 
some implementations implement a SHOULD while others do not. If there is no 
loss of interoperability, by definition the MUST would not be justified in 
any case.

Thanks,

Spencer

From: "Soliman, Hesham" <[email-masked]>

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Nov 2006 09:26:04 -0500

Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for.  I
didn't say examples, I said explanations.  See below ...

On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
> Scott W Brim <[email-masked]> writes:
> 
> ...
>>     omitted.  RFC2119 says that deserves explanation.
> 
> I don't agree with your last sentence. Where exactly does 2119 say
> "that deserves explanation"? 

It says "the full implications must be understood and carefully
weighed before choosing a different course".  How do you expect
implementors to carefully way the full implications if you don't give
them information with which to do so?  Why did you choose to say only
"SHOULD"?  Tell them.  The point is to give implementors the benefit
of the weeks of debate that went on in the WG.  If you say something
SHOULD be done, you should also go on to say, for example, "in the
case of implementations that don't support option Y, it can't, and you
need to take that into account".

> If the IESG is now requring all uses of SHOULD to give examples of
> when the SHOULD might not apply, I think that goes a bit far. In some
> cases, SHOULD is chosen because we can imagine a future spec taking
> advantage of something that would not be consistent with the
> SHOULD. 

If that's the justification for the SHOULD, then that is all you need
to say.

> Also, anyone familiar with WG discussions knows that there is often
> support for SHOULD, but not for MUST.

Absolutely.  This isn't about SHOULD versus MUST, it's about helping
implementors understand your reasoning.

swb

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Nov 2006 09:29:04 -0500

On 11/22/2006 09:04 AM, Spencer Dawkins allegedly wrote:
> It's not that specifications need to explain all possible reasons for
> not following a SHOULD - I agree with your statement that successful
> protocols are used in amazing ways - but I do think listing ONE possible
> reason as justification for a SHOULD instead of a MUST is reasonable.

As I understand it the goal is not just to provide an example, since
that may still leave implementors guessing as to why you said SHOULD
instead of MUST.  Include your reasoning.  You can also include
examples if they help explain that reasoning.

> deployed implementations do something else might very well serve as that

It certainly would.  It would also help if you said what to do with
those deployed implementations as a workaround.

Scott

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 06:34:10 -0800

Hi Spencer,  

 > deployed implementations do something else might very well 

=> Ok, but my other point is that you only use MUST when avoiding it
causes the protocol to break. So, a SHOULD is used when something is
recommended, but its lack would not break the protocol. Now, that
doesn't mean you have to explain how the protocol can be used without
that SHOULD. I don't have to provide an application for something to use
a SHOULD, all I need to know is that it's not a MUST, but recommend that
it be done in a certain way. There are ample examples of that in specs
today. I'd hate to put this, IMO, editorial requirements on spec
writers. 

 > loss of interoperability, by definition the MUST would not 

=> Exactly, which is the case every time the spec in question uses a
SHOULD. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 06:46:59 -0800

Folks, 

In future emails please use this email address for me:
[email-masked].
I won't be reachable on my current email address in a couple of days.

Thanks,
Hesham

 > -----Original Message-----
 > From: Spencer Dawkins [mailto:[email-masked]] 
 > Sent: Thursday, November 23, 2006 1:05 AM
 > To: Soliman, Hesham
 > Cc: General Area Review Team; Jari Arkko; Mark Townsley; Bob 
 > Hinden; Brian Haberman; Thomas Narten; Erik Nordmark; 
 > William Allen Simpson
 > Subject: Re: [Gen-art] RE: gen-art review of 
 > draft-ietf-ipv6-2461bis-09.txt
 > 
 > Hi, Hesham,
 >

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Nov 2006 09:06:04 -0500

...

I don't agree with your last sentence. Where exactly does 2119 say
"that deserves explanation"? Look also at Section 6 of 2119. It says:

> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

The above bolsters the argument that SHOULD is often more appropriate
than MUST.

In my experience, we often use the word SHOULD because we think that
something is the obvious thing to do, but to make it a MUST simply
goes to far. MUST is absolute and allows for no wiggle room, and can
significantly reduce flexibility of future extensions/specs.

If the IESG is now requring all uses of SHOULD to give examples of
when the SHOULD might not apply, I think that goes a bit far. In some
cases, SHOULD is chosen because we can imagine a future spec taking
advantage of something that would not be consistent with the
SHOULD. That is MUCH harder to do when a previous spec says MUST. When
a party a MUST do something, peers sometimes take that to mean that if
the someone doesn't do the MUST, that is a protocol violation and then
do less-than-ideal things (like silently discard a message, return an
error message, etc.)

Thomas

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Nov 2006 10:35:59 -0500

> today. I'd hate to put this, IMO, editorial requirements on spec

This is the difference between SHOULD and MAY.  A MAY is something
that you can do if you want to but not doing it doesn't break the
protocol.  A SHOULD, however, says that the full implications of not
implementing something MUST be understood before choosing not to.
That is, WHY do you recommend that it be done in a certain way?

If you choose not to put these explanations in the protocol spec, at
least put references to the applicability RFC where you do explain them.

swb

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Nov 2006 12:46:59 -0800

Gentlemen,

This document is being recycled at Draft standard.  It has been  
previously reviewed, IESG approved, RFC-Editor edited, and published  
at Proposed and Draft Standard.  It is very widely deployed.  Any  
issues regarding the meaning of SHOULD, MUST, etc. have been already  
dealt with.

I am having a hard time not reading most of the comments in this  
review as a "make work" project.  There isn't an implementations  
problem that is being solved.  This is already widely implemented.   
In deciding to recycle the Draft the IPv6 w.g. was trying to clarify  
some issues that have come up based on the deployment experience  
todate.  Many of the changes from the previous document were finely  
crafted in a lot of working group discussion.  I think it is very  
inappropriate to change them.

Further, making these changes will likely cause confusion in the  
people who have implemented this standard as they might wonder if  
they have to change anything.  So I think this attempt to clarify the  
text, might well have the effect of reducing interoperability.

Overall, I think this kind of review is a wonderful service for new  
specifications going to Proposed Standard the first time before there  
are implementations, but I think it is very worrisome for documents  
that have been through the process several times and are already  
widely implemented.  In my view, for documents that are at this level  
of maturity we should only being making changes that fix critical  
problems.

Bob

---

From: Mark Townsley <[email-masked]>
Date: Wed, 22 Nov 2006 22:03:11 +0100

Bob Hinden wrote:
> problem that is being solved.  This is already widely implemented.  In 
> deciding to recycle the Draft the IPv6 w.g. was trying to clarify some 
> issues that have come up based on the deployment experience todate.  
> Many of the changes from the previous document were finely crafted in 
> a lot of working group discussion.  I think it is very inappropriate 
> to change them.
>
> people who have implemented this standard as they might wonder if they 
> have to change anything.  So I think this attempt to clarify the text, 
> might well have the effect of reducing interoperability.
>
Without having reviewed the document or the review comments, I still 
want to weigh in agreeing with Bob here on principle. When dealing with 
a specification with a lot of deployment behind it, each change to the 
document runs the risk of introducing regression errors in the process. 
Unless the document is severely flawed, I think that the move from PS to 
DS should focus on "bugfixes" more than redesign.

Just my 0.02 EUR...

- Mark

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Nov 2006 18:03:11 -0500

On 11/22/2006 15:46 PM, Bob Hinden allegedly wrote:
> previously reviewed, IESG approved, RFC-Editor edited, and published at
> Proposed and Draft Standard.  It is very widely deployed.  Any issues
> regarding the meaning of SHOULD, MUST, etc. have been already dealt with.
> 
> I am having a hard time not reading most of the comments in this review
> as a "make work" project.  There isn't an implementations problem that
> is being solved.  This is already widely implemented.  In deciding to
> recycle the Draft the IPv6 w.g. was trying to clarify some issues that
> have come up based on the deployment experience todate.  Many of the
> changes from the previous document were finely crafted in a lot of
> working group discussion.  I think it is very inappropriate to change them.
> 
> Further, making these changes will likely cause confusion in the people
> who have implemented this standard as they might wonder if they have to
> change anything.  So I think this attempt to clarify the text, might
> well have the effect of reducing interoperability.

I am not going to argue that you should accept the changes I proposed.
 I will object to almost everything you say because I think your
rhetoric is bogus, and there are implicit accusations that are
unjustified.

I thought seriously before sending out this review.  Technical tweaks
were never an issue.  However -- as I said then -- since this is a
significant protocol, clarity in documentation is very important for
implementors.  You said it yourself just now.  Why did you open up the
RFC?  For clarity.  If you have been through five revisions in the
last year to get the text clear, what is wrong with someone pointing
out clarity issues you missed?  Oh, I know it's hard to send something
back to the Working Group.  How inconvenient.  But you can't say that
the questions I asked were invalid.  If the goal is a clear
specification, see if you can find the answers to the questions I
asked in the specification or any supporting RFC.  For example, when
is it all right for me to include a source address, but omit a link
layer address even if I know it, in a neighbor solicitation?   Right
now there is no information, and in that vacuum an implementor is left
with no resort but to treat the SHOULD as a MUST.  Thus that SHOULD --
and some of the others I listed -- is really a de facto MUST.  If
that's what you intend, that's fine but you should tighten up the
documentation and explicitly say so.  Claiming that things are already
perfectly clear is just not supportable because they are not clear to
me, and I do know something about protocols.  This is why we have
non-WG reviewers.

You say previous implementors might be confused by adding
justifications for SHOULDs, and yet you also say you have made many
changes from the previous document.  Did you think previous
implementors might be confused by the many changes you made?  For
example adding documentation of when it assumptions about DHCPv6 are
implied?  How could previous implementors be confused by your changes
but not the little things I asked about?  Conversely, if you are
confident you had every previous implementor sign off on every change,
then you can do it again.  Do you want your cake or do you want to eat
it?  You can't have a double standard.

Saying all issues "have already been dealt with" is simply arrogant,
because if they had, you could just simply answer my questions.  No
one ever catches everything.  Do you really mean you don't want to go
through another iteration?  Please be straightforward.

The IETF can make a decision to ignore those small ambiguities, but
that decision should be made honestly, with a clear statement that
they aren't big enough to require fixing.  Refusing to acknowledge
them is not a good path to follow.

As to whether mature documents should be reviewed at all ... External
reviews serve different purposes at different times in a document
lifecycle.  Early reviews can make dramatic changes in not only a
protocol but the whole system concept.  Even at this late stage, an
external review is useful because it validates the  Working Group's
(and IESG's) assumptions about clarity.

It's fine with me if you say you understand there are some issues but
you explicitly choose to ignore them.  That's what I expected when I
sent in the review.  Just don't claim that everything is clear, or
that all issues "have already been dealt with".

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Nov 2006 11:48:34 +0100

A couple of thoughts here.

1. It is true that both Gen-ART and the IESG have probably been
looking more critically at SHOULDs. I personally believe that some
SHOULDs are fine without any qualification (i.e. the default words
in 2119 are sufficient guidance) and others need supporting text.
For example, if a timer value is defined as "SHOULD be set to
30 seconds", I think a discussion of when it might be set to
less or more would often be appropriate, not to mention defining
a minimum and maximum. But it's a judgement call, and it seems that
Scott's judgement is different from the authors' in these cases.

2. OTOH, I'd be very surprised if qualifying the SHOULDs would
introduce interoperability problems, if the statement that the
protocol works regardless of the SHOULDs is true.

3. However, I'm quite sensitive to the fact that this is old text
that has been debated for a very long time in the WG, and that for
the PS->DS transition we are above all supposed to look at proven
interoperability.

4. So, bottom line, I don't feel I can challenge the WG consensus
on the current language.

     Brian

---

From: Scott W Brim <[email-masked]>
Date: Sat, 25 Nov 2006 06:07:03 -0500

Thanks, Brian.  That's the sort of thing I was hoping to see.  If the
principles ever have time I am still curious about the technical
questions in the review (which the SHOULD brouhaha buried).

swb

---

From: Scott W Brim <[email-masked]>
Date: Sat, 25 Nov 2006 12:08:20 -0500

On 11/25/2006 12:01 PM, Hesham Soliman allegedly wrote:
> Hi Scott, 
> 
> Are you referring to comments other than the "SHOULD" issue? I responded to
> all of your comments in my first email. If there is anything unclear please
> let us know.
> 
> Hesham

OK.  I'll take it offline for the moment.  Thanks.

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 26 Nov 2006 04:01:29 +1100

Hi Scott, 

Hesham

 > From: Scott W Brim [mailto:[email-masked]]
 > Sent: Saturday, November 25, 2006 10:07 PM
 > To: Brian E Carpenter
 > Cc: [email-masked]; Thomas Narten; Brian Haberman; William Allen
 > Simpson; Soliman, Hesham; General Area Review Team; Erik Nordmark; Jari
 > Arkko; Mark Townsley
 > Subject: Re: [Gen-art] RE: gen-art review of draft-ietf-ipv6-2461bis-
 > 09.txt
 >

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Nov 2006 12:46:13 +0200

I have pretty much the same view as Brian has
below. Indeed, explanation of SHOULDs is often
very useful. For instance, we have seen many
cases where IPv6 or some other technology
is misapplied by folks who interpret SHOULDs
without complete understanding of what the
implications are.

However, adding those explanations is
always a judgment call. And often we might only
know that omitting the action does not cause
major breakage, but at the same time we would
not be able to explain why someone would
omit the action.

Age of the spec is also an input in the
judgment call.

(As a point of formality, I'm NOT requiring the
authors or the WG to add the explanations
for this particular spec unless they want to.
I would like to see the other issues addressed/
discussed from the review, though. It would
be great if you could converge that part of the
discussion in the next day or two, because we
have this document on the Thursday telechat
agenda.)

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Nov 2006 14:38:05 +0100

Jari Arkko wrote:
...
> have this document on the Thursday telechat

The author comment on the other points was "OK",
as logged in my tracker comment. I'm "no objection"
but it would be fine to have those points fixed
up editorially.

      Brian

---

From: Scott W Brim <[email-masked]>
Date: Mon, 27 Nov 2006 09:49:09 -0500

I only have one question left.  Are anycast addresses taken from a
special pool?  I didn't think so.  Is it possible for me to first be
told about a prefix by router A, and then an anycast address that is
within that prefix by router B?  Since anycast addresses have the
override flag set to 0, what would happen?

---

From: "Ralph Droms \(rdroms\)" <[email-masked]>
Date: Tue, 28 Nov 2006 00:08:05 -0500

Comment about DHCPv6 question in line...

- Ralph

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley (townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark; William Allen Simpson; [email-masked]; [email-masked]
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

It's a network config and admin issue.  The router doesn't "learn" or "know" if DHCPv6 is available; rather, the router is explicitly configured by the network admin to advertise the availability of DHCPv6 to hosts.  Presumably, the netowkr admin knows whether DHCPv6 is available and configures the router appropriately.

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 02:18:35 +1100

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley
(townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark;
William Allen Simpson; [email-masked]; [email-masked]
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

It's a network config and admin issue.  The router doesn't "learn" or "know"
if DHCPv6 is available; rather, the router is explicitly configured by the
network admin to advertise the availability of DHCPv6 to hosts.  Presumably,
the netowkr admin knows whether DHCPv6 is available and configures the
router appropriately.

=> Sure, that's why the end result is that the router knows whether DHCPv6
is available or not.

Hesham

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Nov 2006 11:32:57 -0500

> From: Soliman, Hesham [mailto:[email-masked]]
[...]
> It's a network config and admin issue.  The router doesn't "learn" or "know" if DHCPv6 is available; rather, the router is explicitly configured by the network admin to advertise the availability o…

True, but at least in my own implementation experience, I've found
this to be a bit too brittle.

There's no easy way to make sure that the configuration works out
correctly.  If you happen to have a monolithic implementation, you
might be able to cause the "enable DHCPv6 server" configuration knob
to turn these bits automagically so there are no inconsistencies.
However, for those of us with more flexible environments, or for
deployments where the DHCPv6 server is not itself a router,
rationalizing the configuration is infeasible, and it becomes yet
another error-prone task for humans.

If the administrator enables a DHCPv6 server, he must remember to
update the routers with the corresponding prefixes as well.  If he
forgets, then he ends up in a strange state: hosts that don't happen
to hear those routers "right away" (MAX_RTR_SOLICITATIONS) at
interface configuration time may end up running DHCPv6 and working as
he expected, because they briefly enter the "no routers" state.  Hosts
that do happen to hear these bits will fail to run DHCPv6 at all.  The
results are inconsistent.  (Unrelated issues such as STP port blocking
can cause this to happen more often than might otherwise be expected.)

If he shuts down the DHCPv6 server and clears the RA bits, those hosts
that once heard the "use DHCPv6" bits will continue to run DHCPv6
indefinitely, regardless of the setting of these bits.  Nothing in the
protocol stops them from looking for a server.

Worse still, there's no real guarantee that the authority in charge of
administering "routers" is the same as the authority in charge of
"DHCP" administration on a given network.  It's good if that's true,
and the document seems to assume it tacitly, but these sorts of things
sometimes end up on opposite sides of an administrative divide.

Even more strangely, if the DHCPv6 server is handing out only
configuration information (M=0 O=1), then there's no reason at all to
suppose that the use of DHCPv6 has anything to do with the prefix
management imposed by the routers.  They're effectively unrelated
protocols at that point, and the RAs are serving as a configuration
broadcast mechanism.

The one clear purpose of these bits is in distinguishing between the
"managed" and "other" cases so that the DHCPv6 client knows whether to
start with Solicit or Information-Request.  However, on a routerless
network, the client must still do something sane even though these
bits are absent, and a smart enough client can thus be expected to
right itself regardless of the way the server is configured.

Though they're part of the standard, and I'm forced to support them, I
don't think the ``M'' and ``O'' bits have much to recommend themselves
over simply running DHCPv6 on all interfaces by default and perhaps
fixing the DHCPv6 specification to make switching between the two
modes of operation simpler and more consistent.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Nov 2006 15:33:17 -0500

> address. You can't include a prefix in the NA.

I also don't understand the question. The override flag is only
carried in NA messages, and thus refers to the target address (i.e.,
one unicast address).

>  >       Otherwise it SHOULD be included on link layers that have

There is no reason to include it if the source address if the RS is an
unspecified address. By definition, the unspecified address is never
used as a destination address. Thus, the router can't just insert the
source address of an RS into the destination address of an Ra and send
the packet directly. Morever, since there is no source address, there
is no updating of the neighbor cache. I suspect (but have forgotten)
that the MUST NOT is to preclude some mischief from happening if the
router actually did try to use that link-layer address in conjunction
with an unspecified address.

It is also not a MUST to include on link layers that have addresses
because a router doesn't have to respond with a unicast RA back to the
requestor. It can multicast to the all nodes address instead. So the
SHOULD is to give the router the option of sending back a unicast RA.

If there was a more specific reason why the SHOULD was not a MUST, I
don't recall any more why that was.

Now whether any of the above needs to go into the document
explicitely, I have my doubts...

>  >     possibility that the responding router might not know?

yes. But there is little we can do about this.

In hindsight, the M&O bits (IMO) should probably never have been
defined at all. Indeed, they are classic case of "define the field
first, figure out later how to make it useful". The M&O bits were
defined long before we had DHCPv6 in place.

As James Carlson has also observed, life would be simpler if there
were no (protocol) distinction in DHCPv6 between asking for "all"
parameters and asking for "other" parameters. Then we wouldn't need
two bits. And life would be simple if all nodes just invoked DHC
(regardless of what the M&O bits said -- precisely so that the router
wouldn't have to worry about setting them correctly). But some folk
did/will complain about always invoking DHC. On wireless WAN links,
where "every packet costs someone money", folks have made a lot of
noise about NOT having nodes invoke DHC if there is no DHC server
available. In those (heavily managed infrastructures) it is no problem
having the DHC story and the M&O settings on routers be
consistent. However, for home networks, it's less clear how to ensure
things are in sync...

So, no solution is perfect. If you assume a managed infrastructure,
setting the bits correctly is pretty easy. If always invoke DHC, and
DHC isn't actually present, there is an associated inefficiency.

> 3GPP, WiMAX ...etc) out there that define how IPv6 is used in their

I'll also note that the above SHOULD is to some extent an operational
statement, not a protocol statement.  If it is an implementation
statement, it would be far more appropriate to say SHOULD or MUST in
the specific IPv6 over FOO document, rather than this one.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Nov 2006 10:58:54 +0100

> The M&O bits were

And they were discussed to death in the WG before the draft reached
WG consensus. I'm not inclined to reopen that discussion.

(Somebody added [email-masked] to this thread. I have removed it.)

    Brian

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Nov 2006 13:18:48 -0500

Yeah.  I have to agree with James and Brian: in retrospect, the M/O bits are
useless and further discussion at this point is even more useless.

- Ralph