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 narten@us.ibm.com

>    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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------