Subject: narten's review of 2461bis

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Nov 2006 12:04:54 -0500

2006-11-28 review of -09

Note: I did a complete review of the entire document.

Overall: I think this document is in good shape and mostly ready to go
forward. But I found a few things that need clarification and some
probably warrant some additional discussion. Note: I don't see any of
these issues as needing to block this document for a long time. We
should just figure out what to do with them, respin and move on.

Substantive:

Some of other standards track documents have extended ND. Some of
these extensions should be mentioned in this document, as some of them
seem to actually update this document. 

E.g, section 4.2, the reserved field has gotten smaller. All the
defined bits should be listed here. The include:

> Home Agent flag (H bit) in RA [RFC3775]

(And I seem to recall some other  documents using additional bits, but
I'm not sure whether they every became RFCs. Can anyone else recall?)

2461bis should point this out and supply (non-normative) references to
the RFCs.

Same goes for the Prf field added to RAs by RFC 4191

> Router Address (R bit) in Prefix information options [RFC3775]

Ditto.

RFC 3775 also defines:

> 7       Advertisement Interval Option           [RFC3775]

This option is inserted in outgoing RAs, and the value is taken from
the router's MaxRtrAdvInterval value. This one should probably get
mentioned (see more below)

> 8       Home Agent Information Option           [RFC3775]

This one probably doesn't need mentioning.

RFC 3775: says:

>    Routers supporting mobility SHOULD be able to be configured with a
>    smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow
>    sending of unsolicited multicast Router Advertisements more often.
>    The minimum allowed values are:
> 
>    o  MinRtrAdvInterval 0.03 seconds
> 
>    o  MaxRtrAdvInterval 0.07 seconds

This updates/contradicts the current wording in 2461. That doesn't
seem appropriate, and we should sync up 2461bis.

Also, section 8.3 of RFC3775 says:

> 8.3.  All IPv6 Routers
> 
>    All IPv6 routers, even those not serving as a home agent for Mobile
>    IPv6, have an effect on how well mobile nodes can communicate:
>    
>    o  Every IPv6 router SHOULD be able to send an Advertisement Interval
>       option (Section 7.3) in each of its Router Advertisements [12], to
>       aid movement detection by mobile nodes (as in Section 11.5.1).
>       The use of this option in Router Advertisements SHOULD be
>       configurable.
> 
>    o  Every IPv6 router SHOULD be able to support sending unsolicited
>       multicast Router Advertisements at the faster rate described in
>       Section 7.5.  If the router supports a faster rate, the used rate
>       MUST be configurable.
> 
>    o  Each router SHOULD include at least one prefix with the Router
>       Address (R) bit set and with its full IP address in its Router
>       Advertisements (as described in Section 7.2).
> 
>    o  Routers supporting filtering packets with routing headers SHOULD
>       support different rules for type 0 and type 2 routing headers (see
>       Section 6.4) so that filtering of source routed packets (type 0)
>       will not necessarily limit Mobile IPv6 traffic which is delivered
>       via type 2 routing headers.

I'm inclined to say that 2461bis should incorporate the above
recommendations directly.

This document needs an updated Acknowldegments section. That section
should distinguish between what was done for 2461 vs. what was done in
_this_ document. (and it should adhere to the current recommendations
on how to do this in new RFCs, which I haven't checked.) Here is a
strawman (it may need some changes...):

Acknowledgments

   Original section from RFC 2461
   
   The authors would like to acknowledge the contributions of the IPNGWG
   working group and, in particular, (in alphabetical order) Ran
   Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering,
   Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert
   Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas,
   and Susan Thomson.

   Acknowledgements for RFC XXX

   This document updates RFC 2461 and was undertaken to clarify issues
   that have come up since the publication of RFC 2461.  Hesham
   Soliman was the sole editor for this revision of the document.

   Special thanks should be given to [insert names here - I note that
   most of the listed names are the same as those in 2461. Anyway, can
   you take a stab at this Hesham?]

>         CurHopLimit    The default hop limit to be used when sending
>                        (unicast) IP packets.

why only unicast? seems like this should also apply to multicast.  Are
the default values for multicast different  than unicast? (I think the
answer is yes for IPv4, but I'm not sure that applies to IPv6. IPv6
multicast addresses have explicit scoping, whereas IPv4 multicast used
the TTL for that...)

>    The set of addresses assigned to an interface may change over time.
>    New addresses might be added and old addresses might be removed
>    [ADDRCONF]. In such cases the node MUST join and leave the
>    solicited-node multicast address corresponding to the new and old
>    addresses, respectively. Joining the solicited-node multicast address
>    SHOULD be done using the Multicast Listener Discovery [MLD] or
>    [MLDv2] protocols. Note that multiple unicast addresses may map into
>    the same solicited-node multicast address; a node MUST NOT leave the
>    solicited-node multicast group until all assigned addresses
>    corresponding to that multicast address have been removed.

Hmm. should we point to MLD v1 at all? And doesn't the SHOULD make
this  a normative reference? IPv6 node reqirements provides more
guidance on when to use MLD vs. MLDv2. should we include similar text?
Is there some other standards track document to refer to? Or should we
just provide a pointer to node requirements, even though it is only an
informational RFC?

>    A proxy MAY multicast Neighbor Advertisements when its link-layer
>    address changes or when it is configured (by system management or
>    other mechanisms) to proxy for an address.  If there are multiple
>    nodes that are providing proxy services for the same set of addresses
>    the proxies SHOULD provide a mechanism that prevents multiple proxies
>    from multicasting advertisements for any one address, in order to
>    reduce the risk of excessive multicast traffic. This is a requirement
>    on other protocols that need to use proxies for Neighbor
>    Advertisements. An example of a node that performs proxy
>    advertisements is the Home Agent specified in [MIPv6].

not sure the above is right. and MIPv6 doesn't do this AFAIK. maybe we
should change SHOULD to "should consider", or something less strong.

>    Finally, when sending a proxy advertisement in response to a Neighbor
>    Solicitation, the sender should delay its response by a random time
>    between 0 and MAX_ANYCAST_DELAY_TIME seconds.

This seems problematical for MIP, where there is exactly one
proxy. Indeed, we should relax the requirements here so that delays
are only required if there is a real danger of too many responses at
the same time.

Editorial

change my email address to [email-masked]

>    Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan,

s/Deering/Deering,/

>                     - it is covered by one of the link's prefixes, or

s/prefixes/prefixes (e.g., as indicated by the on-link flag of a Prefix
Infromation Option)

   proxy       - a router that responds to Neighbor Discovery query
s/router/node/?   
                 messages on behalf of another node.  A router acting
                 on behalf of a mobile node that has moved off-link
                 could potentially act as a proxy for the mobile
                 node.

>    random delay seed
>                - If a pseudo-random number generator is used in
>                  calculating a random delay component, the generator
>                  should be initialized with a unique seed prior to being
>                  used. Note that it is not sufficient to use the
>                  interface token alone as the seed, since interface
>                  tokens will not always be unique.  To reduce the
>                  probability that duplicate interface tokens cause the
>                  same seed to be used, the seed should be calculated
>                  from a variety of input sources (e.g., machine
>                  components) that are likely to be different even on
>                  identical "boxes".  For example, the seed could be
>                  formed by combining the CPU's serial number with an
>                  interface token.
>

Hmm, what is an interface token. s/token/identifier/? Looking through
the document, I think all uses of the term "interface token"
can/should be replaced with "interface identifier"

>                     applications that need it(e.g., using multicast

s/(/ (/

>    solicited-node multicast address
>                - a link-local scope multicast address that is computed
>                  as a function of the solicited target's address.  The
>                  function is described in [ADDR-ARCH]. The function is
>                  chosen so that IP addresses which differ only in the
>                  most significant bits, e.g., due to multiple
>                  prefixes associated with different providers, will map
>                  to the same solicited-node address thereby reducing the
>                  number of multicast addresses a node must join.

make clear in last sentence that join refers to "at the link layer?"

>            contain link-layer addresses that differ depending on who

s/on/on, e.g.,/

>      Proxy advertisements - A router willing to accept packets on behalf

s/router/node/ (I'm on the fence for this one actually, but I think
the first use of "router" in this definition would more properly be
called "node")

>       Neighbor Unreachability Detection is part of the base

s/base/base,/

>                       provided on point to point links, and interfaces

s/point to point/point-to-point/

>                       not specified in this document.  Note that if
> 
>                       hosts support manual configuration of a list of

Format: why is there a blank line here?

>       Prefix Information
>                      These options specify the prefixes that are on-link
>                      and/or are used for address autoconfiguration.  A
>

and MIP6 stuff...

>       Prefix Information
>                      These options specify the prefixes that are on-link
>                      and/or are used for address autoconfiguration.  A
>                      router SHOULD include all its on-link prefixes
>                      (except the link-local prefix) so that multihomed
>                      hosts have complete prefix information about on-
>                      link destinations for the links to which they
>                      attach.  If complete information is lacking, a
>                      multihomed host may not be able to choose the
>                      correct outgoing interface when sending traffic to
>                      its neighbors.
>

use word other than multihomed (which is seriously overloaded).

suggest
s/multihomed hosts/hosts with multiple interfaces/ do this throughout
document, other than perhaps Appendix A, where its more obvious what
the context is.

>       L              1-bit on-link flag.  When set, indicates that this
>                      prefix can be used for on-link determination.  When
>                      not set the advertisement makes no statement about
>                      on-link or off-link properties of the prefix.  For
>                      instance, the prefix might be used for address
>                      configuration with some of the addresses belonging
>                      to the prefix being on-link and others being off-
>                      link.

Clarify "no statement" wording? (see email thread)

>                      determination.  A value of all one bits
>                      (0xffffffff) represents infinity.  The Valid
>                      Lifetime is also used by [ADDRCONF].

Due to DOS concerns, an infinity value is a Bad Idea. But not worth
dealing with here.

>       MinRtrAdvInterval
>                      The minimum time allowed between sending
>                      unsolicited multicast Router Advertisements from
>                      the interface, in seconds.  MUST be no less than 3
>                      seconds and no greater than .75 *MaxRtrAdvInterval.
> 
>                      Default: 0.33 * MaxRtrAdvInterval

value has been updated by MIP6

>                      Default:  The value specified in the "Assigned
>                      Numbers" RFC [ASSIGNED] that was in effect at the
>                      time of implementation.

better reference? http://www.iana.org/assignments/ip-parameters, then
scroll to "IP TIME TO LIVE PARAMETER" (but not sure how to say that in
an RFC, so current reference is probably best we can do. sigh.)

>                    Automatic address configuration [ADDRCONF]
>                    defines additional information associated with
>                    each the prefixes:
>

change term "automatic" to stateless for consistency? Yes. Do this
throughout document. The term "automatic" is not used much in the
document, and is not a term that the WG has ever used. "stateless"
addrconf is the widely understood definition

>    advertising interface.  Routers respond to Router Solicitations sent
>    to the all-routers address and verify the consistency of Router
>    Advertisements sent by neighboring routers.
>

Is this actually true?

I didn't find hardly any text about this in 2461. Also, DNAv6 seems to
be  significantly raising the bar in terms of what routers  need to
keep track of w.r.t. other routers.

>    advertising interfaces).  In addition, the host MUST insure that

s/insure/ensure/?

>     - Cur Hop Limit values (except for the unspecified value of zero
>       other inconsistencies SHOULD be logged to system network
>       management).
>     - Values of the M or O flags.
> 
>     - Reachable Time values (except for the unspecified value of zero).

missing space between 1st and 2nd item

>    Once the host sends a Router Solicitation, and receives a valid
>    Router Advertisement with a non-zero Router Lifetime, the host MUST
>    desist from sending additional solicitations on that interface, until
>    the next time one of the above events occurs.  Moreover, a host
>    SHOULD send at least one solicitation in the case where an
>    advertisement is received prior to having sent a solicitation.
>    Unsolicited Router Advertisements may be incomplete (see Section
>    6.2.3); solicited advertisements are expected to contain complete
>    information.

Don't agree with that last sentence. better:

Responses to solicited advertisements are expected to provide complete
information. 

>       - All included options have a length that is greater than zero.
> 
>       - If the IP source address is the unspecified address, the IP
>      destination address is a solicited-node multicast address.
> 
>       - If the IP source address is the unspecified address, there is no
>         source link-layer address option in the message.

formatting of middle item is off...

>    for the source of such a message, Address Resolution will be required
>    before unicast communications with that address to begin. This is

s/to begin/can begin/

>          Different than the already recorded address).

s/Different/different/

>          Receipt of an unsolicited advertisement, however, suggests that

s/suggests/may indicate/

>    that has moved off-link.  The mechanisms used by proxy are identical
>    to the mechanisms used with anycast addresses.
> 

s/identicial/essentially the same/ (anycast NAs have delay associated
with them.)

>             MAX_ANYCAST_DELAY_TIME            1 second

too high. why should this be higher than the delay time for a RA?

>         sending host must always send packets out the interface
>         corresponding to the outgoing packet's source address.  Note
>         that this issue never arises with non-multihomed hosts; they
>         only have one interface.

Add. Additional discussion on this topic can be found in Section
3.3.4.2 of [RFC 1122?]  under the "Strong ES Model" and "Weak ES
Model" headings.

>     - The sender of a Router Solicitation is implicitly assumed to be a
>       host since there is no need for routers to send such messages.

Is this desirable?

>    information the receipt of the message will cause the IsRouter flag

s/information/information,/

>    implementation it may be possible to piggyback the reachability

s/implementation/implementations,/

>    Negative advise (e.g. from TCP when there are excessive

s/e.g./e.g.,/

>    Note that an implementation can not use negative upper-layer advise
>    as a replacement for the Neighbor Unreachability Detection algorithm.
>    Negative advise (e.g. from TCP when there are excessive

s/advise/advice/ (twice above)

>    when the path from the receiver of the data is not functioning
>    causing, none of the acknowledgement packets to reach the sender.

s/functioning causing,/functioning, causing/

>       none zero values only.

s/none zero/non-zero/

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Nov 2006 11:40:31 +0100

> seem to actually update this document. 

I don't see how we can do that in a Draft Standard, since those
documents are presumably only Proposed Standard.

     Brian

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Nov 2006 06:21:21 -0500

> documents are presumably only Proposed Standard.

I think some of them can be mentioned in a non-normative way. For
example, the definition of additional bits out of the reserved
field. There is no reason why we can't point out that those bits have
been used by other documents and point to them. The ND spec doesn't
have to say "you SHOULD or MUST" do those specs as part of ND. Just
saying the "bits are used by foo" with an informative reference seems
fine.

For changes to the router intervals, that seems like the kind of minor
change/clarification that has been allowed in other documents. And
note that we are _recycling_ at draft, not _advancing_ to draft.

If the process does _not_ allow us to make those kind of changes, I
think we've got an even bigger problem that I had thought. It defies
logic to have two different standards track document basically
contradict each other on what is allowed for timers.

But to be specific, which of the issues I flagged as "substantive"
(which I used to flag changes that the WG needed to see) do you think
would prevent reissuing the document at draft?

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Nov 2006 12:53:21 +0100

> contradict each other on what is allowed for timers.

Yes. But it is a formal problem caused by the downref rules.

> would prevent reissuing the document at draft?

I haven't done that analysis. I agree that informative pointers will
probably work. I'm not sure that Jari will get the RFC Editor notes
worked out before today's IESG call, though...

     Brian

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 30 Nov 2006 23:09:10 +1100

Hi Thomas, 

 > should just figure out what to do with them, respin and move on.

=> Agreed.

 > seem to actually update this document.

=> We discussed these extensions when the bis was prepared, I think we
discussed all of them. At the time the WG didn't agree with even including
the H bit, the R bit, the changes in inter-RA timers ...etc Adding any of
those issues to the current draft was rejected by a large margin. I
personally thought it would make sense to include things like the H and R
bits in the RA, but most people didn't agree at the time. This was around
the Seoul IETF if memory serves me right. 

 > Same goes for the Prf field added to RAs by RFC 4191

=> I'm fine with reopeining these issues but we need to see a change of
position on this. I think those particular flags might be problematic in a
DS though. They're certainly not backward compatible.

 > > Router Address (R bit) in Prefix information options [RFC3775]

=> Ditto :)

 > seem appropriate, and we should sync up 2461bis.

=> But how do we do that? We can't change these values in 2461bis can we? 

 > recommendations directly.

=> What about backward compatibility? I mean the R bit for instance is not
backward compatible.

 >    you take a stab at this Hesham?]

=> Sure, I've already added a couple of new names there. I think I forgot
Pekka but I included all others I think.

 > multicast addresses have explicit scoping, whereas IPv4 multicast used

=> Right. We could just s/(unicast)/. 

 > this  a normative reference? 

=> Yes to both questions I think. If we didn't point to MLDv1 then the
change woulod not be backward compatible. I.e. using MLDv2 only would break
old implementations. As for the second question, I agree that it makes MLDv2
normative but I was hoping the "or" would get us out of this dilemma.

    IPv6 node reqirements provides more
 > just provide a pointer to node requirements, even though it is only an

=> All good questions, does anyone have a suggestion here? I can't think of
one yet. I'm also not sure if we need to give recommendations for MLDv1 Vs
v2 if there is another document that does that in a generic manner (i.e. not
specific to this doc). 

 > should change SHOULD to "should consider", or something less strong.

=> That's ok with me, I think the requirement is important to keep. I agree
that MIPv6 doesn't strictly follow this requirement.

 > are only required if there is a real danger of too many responses at

=> Right, but this is not mandatory language so an implementer can ignore
this guidline I think if the reasons given do not apply. 

 > Editorial

=> Ok to all, except the ones where there are questions below. 

 > too high. why should this be higher than the delay time for a RA?

=> You're asking me? :) I don't know but not sure if it should be changed
now.

 > 3.3.4.2 of [RFC 1122?]  under the "Strong ES Model" and "Weak ES

=> Fine with me.

 > >       host since there is no need for routers to send such messages.

=> I think the sentence is superfluous, I'm quite happy to remove it. Anyone
has problems with removing this? 

Thanks,
Hesham

---

From: Brian Haley <[email-masked]>
Date: Thu, 30 Nov 2006 10:27:17 -0500

> note that we are _recycling_ at draft, not _advancing_ to draft.

A discussion about advertisement intervals happened back on 10/29/06 - 
Hesham raised this issue, and Raj and others agreed we should not change 
the wording:

> I like Jinmei's proposal of rejecting the issue as far as changing 2461bis
> value goes. Because even the Max value of 2999 seconds is still not good
> enough for some links.
> 
> So I think it is best to let IPv6 over foo specific documents specify what
> router configuration variables are modified or over-ridden (from the default
> 2461bis). 
> 
> -Basavaraj

Adding things from 3775 back-into 2461bis doesn't seem like the right 
thing to do, it will change the router requirements to be 2461bis + some 
parts of 3775, even though that router might never be a home agent.  I 
think the "layering" of RFCs works just fine in this instance.

-Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 30 Nov 2006 14:05:49 -0800

> multicast addresses have explicit scoping, whereas IPv4 multicast used

I don't know how much we've discussed it, but I think IPv6 needs to have 
a default hoplimit for multicast of 1, just like IPv4. Applications can 
use IPV6_MULTICAST_HOPLIMIT etc to set a different value.

 > should change SHOULD to "should consider", or something less strong.

It might make sense to clarify the wording.
AFAIK MIPv6 avoids having multiple HAs on the home link proxy for the 
same MN, by having the MN only register with one of its HAs.

 > are only required if there is a real danger of too many responses at

I don't even remember that text. Does anybody implement it that way?

I can see the case for a random delay if there are lots of nodes 
responding to the same anycast address on the same link, but that isn't 
the common way anycast is used in IPv4.

    Erik