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

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Dec 2004 16:44:36 +0200 (EET)

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.

substantial
-----------

==> this spec needs at least an IANA Considerations section, stating at
least:
   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
registry.

                         AdvValidLifetime
                              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
                              ways:

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

NORMATIVE

    [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
problems..

    [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

semi-editorial
--------------

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

==> 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
    steps:

==> "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
    follows:

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

editorial
---------

    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.
                  FF02::1

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

    A solicitation that passes the validity checks is called a "valid
    solicitation".
...
    An advertisement that passes the validity checks is called a "valid
    advertisement".
...
    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
    elsewhere.

==> 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
    router.

==> 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:
                 http://www.iana.org/numbers.html

==> 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Dec 2004 16:44:36 +0200 (EET)

substantial
-----------

                         AdvValidLifetime

NORMATIVE

semi-editorial
--------------

For instance, a

editorial
---------

    link-layer address

..
..
..

==> s/insures/ensures/

[issuing redirects]

On the

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Dec 2004 10:40:06 +0200 (EET)

On Tue, 14 Dec 2004, Pekka Savola wrote:
> 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.

I went through one implementation and have a couple of additional 
comments wrt suitability for DS/clarify.

1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you 
SHOULD send a final RA with zero Router Lifetime.

At least a couple of implementations do send out final RAs with zero 
lifetime when the RA process is killed, but do not have 'state' which 
monitors whether AdvSendAdvertisements gets disabled or not on an 
interface. (e.g., at HUP signal)

Are there implementations of this?

2) section 6.2.5: if system management disables IP forwarding, 
subsequent RAs MUST set the Router Lifetime to zero.

I've seen no one implementing this (though many implement checks whent 
the RA process starts up).  This either requires polling forwarding 
status constantly, or providing some kind of notifications when IP 
forwarding changes from on to off.  Implementations?

3) section 6.2.7: RA consistency says like:
     - Cur Hop Limit values (except for the unspecified value of zero).

It is ambiguous what the ()'s means.  A couple of possibilities:
  a) if "my Cur Hop Limit" is zero, ignore consistency completely
  b) if "my Cur Hop Limit" is zero, allow the others to have zero Cur 
Hop Limit, otherwise it's inconsistent
  c) if "my Cur Hop Limit" is non-zero, allow the others to have same 
Cur Hop Limit, otherwise it's inconsistent
  d) if "my Cur Hop Limit" is non-zero, allow the others to have same 
Cur Hop Limit or zero, otherwise it's inconsistent

This needs to be clarified.

4) section 6.2.8: if the link-local address of the router changes, it 
should multicast a few RAs from the old address with zero router 
lifetime, and a few from the new address. (SHOULD).

I haven't seen this implemented.   Similar reasons as 2).  Anyone ?

---

From: Bob Hinden <[email-masked]>
Date: Thu, 16 Dec 2004 10:57:22 -0800

Pekka,

At 12:40 AM 12/15/2004, Pekka Savola wrote:
>>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.
>
>I went through one implementation and have a couple of additional comments 
>wrt suitability for DS/clarify.

I think we need some feedback from the ADs here.

RFC2461 is already at Draft standard.  I don't think we need to do an 
extensive implementation review again (except, of course, if were adding 
new features).  If we are all very sure that a feature isn't implemented, 
then I don't have any personal objections to removing it.  As long as we 
are very sure.

Likewise, the reference to the Address Architecture (currently at Proposed 
standard) existed in RFC2461, so it's not clear it is a problem.

Getting the Address Arch to Draft standard is a good idea that we will try 
to make more progress on.

Thanks,
Bob

>1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you SHOULD 
>send a final RA with zero Router Lifetime.
>
>2) section 6.2.5: if system management disables IP forwarding, subsequent 
>RAs MUST set the Router Lifetime to zero.
>
>I've seen no one implementing this (though many implement checks whent the 
>RA process starts up).  This either requires polling forwarding status 
>constantly, or providing some kind of notifications when IP forwarding 
>changes from on to off.  Implementations?
>
>  b) if "my Cur Hop Limit" is zero, allow the others to have zero Cur Hop 
> Limit, otherwise it's inconsistent
>  c) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur 
>  d) if "my Cur Hop Limit" is non-zero, allow the others to have same Cur 
> Hop Limit or zero, otherwise it's inconsistent
>
>should multicast a few RAs from the old address with zero router lifetime, 
>and a few from the new address. (SHOULD).
>