[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt

On Mon, 1 Nov 2004, Brian Haberman wrote:
    This begins a 2 week IPv6 working group last call on recycling:

	Title		: Neighbor Discovery for IP version 6 (IPv6)
	Author(s)	: T. Narten, et al.
	Filename	: draft-ietf-ipv6-2461bis-01.txt
	Pages	: 86
	Date		: 2004-10-29

at Draft Standard.  Substantive comments should be directed to
the mailing list.  Editorial comments can be sent to the document
editor.  This last call will end on 11/15/2004.

Sorry for being a _lot_ late, but this is a long document, and I didn't see other reviews.. so here goes.

In short, this still needs at least one revision. Jinmei also had some O/M/DHCPv6 consistency issues which probably need to be addressed. There is some specification which I don't think has been implemented and should be removed unless anyone jumps up. There is a normative reference to addr-arch which is still PS, and this is not acceptable.


==> this spec needs at least an IANA Considerations section, stating at
1) the allocation guidelines for ND option types/codes (Standards Action? IETF Consensus?)
2) that no IANA action is required for ICMPv6 types, beyond updating
the ICMPv6 codepoints to refer to this RFC instead of RFC2461 in their

                             The value to be placed in the Valid
                             Lifetime in the Prefix Information
                             option, in seconds.  The designated value
                             of all 1's (0xffffffff) represents
                             infinity.  Implementations MUST allow
                             AdvValidLifetime to be specified in two

                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified
                                 time in the future, or

                               - a fixed time that stays the same in
                                 consecutive advertisements.

==> AFAIK, the first option has not been implemented; I've at least not seen
in done.  Therefore unless someone shows that there are two implementations
of this, this must be removed. (The same for AdvPreferredLifetime, and a bit
in section 6.2.7.)

      Note: Implementations can choose to process the on-link aspects of
      the prefixes separately from the address autoconfiguration aspects
      of the prefixes by, e.g., passing a copy of each valid Router
      Advertisement message to both an "on-link" and an "addrconf"
      function.  Each function can then operate independently on the
      prefixes that have the appropriate flag set.

==> similar to above, has this been implemented ?  Not a as big issue as
above for me, because this is just an implementation note.

   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.

==> does anyone implement this SHOULD?  Note that this does not give hints
how to even go about doing that.  If not, remove.


   [ADDR-ARCH]  Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 2373, July 1998.

==>replace with 3513.  However, there is one big problem here.  addrarch is
PS, while this is going for DS.  DS cannot have normative ref to PS.  It is
not clear whether ADDR-ARCH can be put in as informative reference, the text
seems to be relying on it pretty heavily.  OK with me, but there may be

   [MLD]        Deering, S., Fenner, W, and B. Haberman, "Multicast
                Listener Discovery for IPv6", RFC 2710, October 1999.

==> this is also PS and cannot be referred to normatively.

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

==> this must be over at the normative refs


     Inbound load balancing - Nodes with replicated interfaces may want
           to load balance the reception of incoming packets across
           multiple network interfaces on the same link.  Such nodes
           have multiple link-layer addresses assigned to the same
           interface.  For example, a single network driver could
           represent multiple network interface cards as a single
           logical interface having multiple link-layer addresses.

           Load balancing is handled by allowing routers to omit the
           source link-layer address from Router Advertisement packets,

==> this is conflicting. The first para discusses generic inbound load
balancing, the second load balancing that applies only to routers w/ RAs. How do hosts perform inbound load balancing? Needs text tweaking..

      Unlike in IPv4 Router Discovery the Router Advertisement messages
      do not contain a preference field.  The preference field is not
      needed to handle routers of different "stability"; the Neighbor
      Unreachability Detection will detect dead routers and switch to a
      working one.

==> preference has been plugged back, though not for stability reasons. I'd suggest just removing this paragraph.

      Placing address resolution at the ICMP layer makes the protocol
      more media-independent than ARP and makes it possible to use
      standard IP authentication and security mechanisms as appropriate.

==> the latter part of this sentence is a bit questionable, as this probably
referred to using IPsec.  Still, there is a benefit of being able to use a
single SEND mechanism for _all_ link types.  Text tweaking needed.

     variable MTU   - Neighbor Discovery allows routers to specify a MTU
                      for the link, which all nodes then use.  All nodes
                      on a link must use the same MTU (or Maximum
                      Receive Unit) in order for multicast to work
                      properly.  Otherwise when multicasting a sender,
                      which can not know which nodes will receive the
                      packet, could not determine a minimum packet size
                      all receivers can process.

==> the last sentence is not 100% accurate.  It's not MTU at stake, it's the
receiver's MRU (for processing the packet) or last-hop router's MTU (for
sending the packet on the last links).  Might need minor text tweak.

 If the bridges do not generate ICMP
                     Packet Too Big messages, communicating nodes will
                     be unable to use Path MTU to dynamically determine
                     the appropriate MTU on a per-neighbor basis.  In
                     such cases, routers use the MTU option to specify
                     the maximum MTU value that is supported by all

==> s/routers use/routers can be configured to use/ -- there is no magic to
do this automatically..

6.2.8.  Link-local Address Change

   The link-local address on a router SHOULD change rarely, if ever.

==> this is an improper use of upper-caps.  Just make it lowercase.

For instance, a
   mobile node, using [MIPv6], moving to a new link would need to
   discover such movement as soon as possible to minimize the amount of
   packet losses resulting from the change in its topological movement.
   Router Solicitations provide a useful tool for movement detection in
   Mobile IPv6 as they allow mobile nodes to determine movement to new
   links. Hence, if a mobile node received link layer information
   indicating that movement might have taken place, it MAY send a Router
   Solicitation immediately, without random delays. The strength of such
   indications should be assessed by the mobile node's implementation
   and is outside the scope of this specification.

==> it might not hurt to discuss the potential pitfalls of this approach
somewhere.  For example, n case the link indications are shaky, or just hints,
and there is a significant number of MNs on a link, this could result in an
RS storm.

   - The Target Address is a "valid" unicast or anycast address
      assigned to the receiving interface [ADDRCONF],

    - The Target Address is a unicast address for which the node is
      offering proxy service, or

    - The Target Address is a "tentative" address on which Duplicate
      Address Detection is being performed [ADDRCONF].

If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD be set to zero. [...]

==> the middle bullet point appears to be inconsistent with the further
specification.  That is, shouldn't an anycast address also be acceptable
(not that the node could tell it's anycast address :)

   If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happens.
   Otherwise, the receiving node performs the following

==> "one of two" ?  You do not specify or clearly refer to either
one of these.  Needs rewording.

   If the target's Neighbor Cache entry is in any state other than
   INCOMPLETE when the advertisement is received, processing becomes
   quite a bit more complex.  If the Override flag is clear and the
   supplied link-layer address differs from that in the cache, then one
   of two actions takes place: if the state of the entry is REACHABLE,
   set it to STALE, but do not update the entry in any other way;
   otherwise, the received advertisement should be ignored and MUST NOT
   update the cache.  If the Override flag is set, both the Override
   flag is clear and the supplied link-layer address is the same as that
   in the cache, or no Target Link-layer address option was supplied,
   the received advertisement MUST update the Neighbor Cache entry as

==> AFAICS, you can remove 'both the Override flag is clear and' here,
because the same result happens if the Override flag is set.

   A router MUST limit the rate at which Redirect messages are sent, in
   order to limit the bandwidth and processing costs incurred by the
   Redirect messages when the source does not correctly respond to the
   Redirects, or the source chooses to ignore unauthenticated Redirect
   messages.  More details on the rate-limiting of ICMP error messages
   can be found in [ICMPv6].

==> 'or the source chooses to ignore unauthenticated Redirect
   messages' smells quite a bit from a leftover of IPsec AH times.  Reword?

   An example of denial of service attacks is that a node on the link
   that can send packets with an arbitrary IP source address can both
   advertise itself as a default router and also send "forged" Router
   Advertisement messages that immediately time out all other default
   routers as well as all on-link prefixes.

==> 'on-link' is not accurate.  Using these mechanisms, you can't capture
_all_ on-link traffic as that goes between the nodes.  You can capture that
e.g. by advertising more specifics in RAs, with NA/ND spoofing, etc., but
the sentence does not seem to be 100% correct.

    o Removed the on-link assumption in section 5.2

==> add an informational reference to draft-ietf-v6ops-onlinkassumption here, as that doc captures the reasoning for the change.


   link-layer address
               - a link-layer identifier for an interface.  Examples
                 include IEEE 802 addresses for Ethernet links and E.164
                 addresses for ISDN links.

==> please remove the ISDN E.164 example, that's too crufty to be here..

   non-broadcast multi-access (NBMA)
                  - a link to which more than two interfaces can attach,
                    but that does not support a native form of multicast
                    or broadcast (e.g., X.25, ATM, frame relay, etc.).

Note that all link types (including NBMA) are

==> kill the extra empty line.

   all-nodes multicast address
               - the link-local scope address to reach all nodes.

==> s/nodes./nodes,/, s/1/1./ -- the same with all-routers.

   A solicitation that passes the validity checks is called a "valid
   An advertisement that passes the validity checks is called a "valid
   A Neighbor Solicitation that passes the validity checks is called a
   "valid solicitation".
   A Neighbor Advertisements that passes the validity checks is called a
   "valid advertisement".

==> I'd rewrite these to be "valid router solicitation", "valid router
advertisement", "valid neighbor solicitation", etc.

6.3.4.  Processing Received Router Advertisements

   When multiple routers are present, the information advertised
   collectively by all routers may be a superset of the information
   contained in a single Router Advertisement.  Moreover, information
   may also be obtained through other dynamic means, such as stateful
   autoconfiguration.  Hosts accept the union of all received
   information; the receipt of a Router Advertisement MUST NOT
   invalidate all information received in a previous advertisement or
   from another source.  However, when received information for a
   specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a
   specific Prefix) differs from information received earlier, and the
   parameter/option can only have one value, the most recently-received
   information is considered authoritative.

==> it might not hurt to add an explicit reference to section 6.2.7 on the
consistency -- maybe even replacing the duplicate list here..

   Before a host sends an initial solicitation, it SHOULD delay the
   transmission for a random amount of time between 0 and
   MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate congestion when
   many hosts start up on a link at the same time, such as might happen
   after recovery from a power failure.  If a host has already performed
   a random delay since the interface became (re)enabled (e.g., as part
   of Duplicate Address Detection [ADDRCONF]) there is no need to delay
   again before sending the first Router Solicitation message. In some
   cases, the random delay MAY be omitted if necessary. [...]

==> please split this ridiculously long paragraph to at least two -- maybe
before "In some cases,".

  interface should be used.  Using the prompting packet's source
   address when possible insures that the recipient of the Neighbor
   Solicitation installs in its Neighbor Cache the IP address that is

==> s/insures/ensures/

[issuing redirects]
      - the router determines that a better first-hop node resides on
        the same link as the sending node for the Destination Address of
        the packet being forwarded, and

==> maybe s/determines/determines using unspecified mechanisms/ that this is
out of scope of this spec.

  The trust model for redirects is the same as in IPv4.  A redirect is
   accepted only if received from the same router that is currently
   being used for that destination.  It is natural to trust the routers
   on the link.  If a host has been redirected to another node (i.e.,
   the destination is on-link) there is no way to prevent the target
   from issuing another redirect to some other destination.  However,
   this exposure is no worse than it was; the target host, once
   subverted, could always act as a hidden router to forward traffic

==> add the empty line before the start of this paragraph
==> "than it was" --> what does this refer to ?

On the
   other hand, many of the threats discussed in this section are less
   effective, or non-existent, on point-to-point links, or cellular
   links where hosts share links with one neighbor, i.e. the default

==> s/hosts share links with one/a host shares a link with only one/ ?

   [ASSIGNED]   Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
                RFC 1700, October 1994. See also:

==> this should probably be replaced with RFC3232 ("Assigned Numbers: RFC
1700 is Replaced by an On-line Database").

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6