Subject: Editorial comments on draft-ietf-6man-subnet-model-06

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Dec 2009 10:42:37 -0800

I had some editorial questions and comments on 
draft-ietf-6man-ipv6-subnet-model-06 and I asked Thomas about that 
(since he contributed some new text in this area). Based on Thomas and I 
discussion this, here are some suggested edits.

Throughout the document the term "on-link" is still not used precisely
in all cases. It is important to note that "on-link" is a relative
statement, referring to one node's perspective. Other nodes on the
same link may not have the same understanding that a particular
destination is "on-link".

---

This doesn't look quite right:
    1.  The original Neighbor Discovery (ND) specification [RFC4861] was
        unclear in its usage of the term on-link in a few places.  In
        IPv6, an address is considered to be on-link (with respect to a
        specific link), if the address has been assigned to an interface
        attached to that link.

I read this as if the admin on node A configures some random IPv6
address on an interface, then magically other nodes on the link will
consider it to be on-link. It is clear that the address *is* on-link
once it is configured, but it can't be *considered to be* on-link by
others unless there is some protocol to convey that.

The text would make sense if we just dropped "considered to be" above. 
But a better rewrite would be to say:
    1.  The original Neighbor Discovery (ND) specification [RFC4861]
        was unclear in its usage of the term on-link in a few places.
        In IPv6, an address is on-link (with respect to a specific
        link), if the address has been assigned to an interface
        attached to that link.  Any node attached to the link can send
        a datagram directly to an on-link address without forwarding
        the datagram through a router.  However, in order for a node to
        to know that a destination is on-link, it must obtain
        configuration information to that effect.  In IPv6, there are
        two main ways of maintaining information about on-link
        destinations.  First, a host maintains a Prefix List that
        identifies ranges of addresses that are to be considered
        on-link.  Second, Redirects can identify individual
        destinations that are on-link; such Redirects update the
        Destination Cache.

---

I'm also confused by the use of Neighbor Cache in section 2. AFAIK it is
the prefix list plus the *destination cache* (plus default router list)
which corresponds to the forwarding table in a host. The neighbor cache
is merely a generalization of the ARP cache in IPv4. The text uses
"neighbor cache" in two places where I'd expect to see "destination cache".
Thus I think we need to change FROM
        The conceptual sending algorithm of [RFC4861] defines a Prefix
        List and Neighbor Cache.  The combination of Prefix List and
        Neighbor Cache form what many implementations consider to be the
        IP data forwarding table for a host.
TO
        The conceptual sending algorithm of [RFC4861] defines a Prefix
        List and Destination Cache.  The combination of Prefix List and
        Destination Cache form what many implementations consider to be the
        IP data forwarding table for a host.

---

Later we have an extra '-' appear that doesn't existing in the quoted
text in RFC 4861. The draft contains
           If the Source Address is not the unspecified address and, on-
           link layers that have addresses, the solicitation includes a

But the text in RFC 4861 says
    description applies.  If the Source Address is not the unspecified
    address and, on link layers that have addresses, the solicitation
    includes a Source Link-Layer Address option, then the recipient

The distinction between "on link layer" (one could also say "for link
layers") and "on-link layers" might be important, hence I think the
misquote should be fixed.

---

This should be "Destination Cache" instead of "Neighbor Cache":
        determination can affect the state of ND: through updating the
        Prefix List or the Neighbor Cache.  Through deprecating the last

---

Old:

>    IPv4 implementations typically associate a netmask with an address
>    when an IPv4 address is assigned to an interface.  That netmask
>    together with the IPv4 address designates an on-link prefix.
>    Addresses that are covered by this prefix are viewed as on-link i.e.,
>    traffic to these addresses is not sent to a router.  See section
>    3.3.1 in [RFC1122].  Prior to the deployment of Classless Inter-
>    Domain Routing (CIDR), an address's netmask could be derived directly
>    from the address.  In the absence of specifying a specific netmask
>    when assigning an address, some implementations would fall back to
>    deriving the netmask from the class of the address.

New:

    IPv4 implementations typically associate a netmask with an address
    when an IPv4 address is assigned to an interface.  That netmask
    together with the IPv4 address designates an on-link prefix.  Nodes
    consider addresses covered by an on-link prefix to be directly
    attached to the same link as the sending node, i.e., they send
    traffic for such addresses directly rather than to a router.  See
    section 3.3.1 in [RFC1122].  Prior to the development of subnetting
    [RFC950] and Classless Inter-Domain Routing (CIDR) [RFC1519], an
    address's netmask could be derived directly from the address simply
    by determining whether it was a Class A, B or C address.  Today,
    assigning an address to an interface also requires specifying a
    netmask to use.  In the absence of specifying a specific netmask
    when assigning an address, some implementations would fall back to
    deriving the netmask from the class of the address.

---

>    The reception of a Prefix Information Option (PIO) with the L-bit set
>    [RFC4861] and a non-zero valid lifetime creates (or updates) an entry
>    in the Prefix List.  All the prefixes that are on the Prefix List,
>    i.e., have not yet timed out, are considered to be on-link.

change last sentence to:

    All prefixes on a host's Prefix List, i.e., have not yet timed out,
    are considered to be on-link by that host.

---

>    The on-link definition in the Terminology section of [RFC4861], as
>    modified by this document, defines the complete list of cases where
>    an address is considered on-link.  Individual address entries can be

Change sentence to:

     The on-link definition in the Terminology section of [RFC4861], as
     modified by this document, defines the complete list of cases
     where a node considers an address to be on-link.

---

>    IPv6 packets sent using the Conceptual Sending Algorithm as described
>    in [RFC4861] only trigger address resolution for IPv6 addresses that
>    are on-link.  Packets to any other address are sent to a default

New:

     IPv6 packets sent using the Conceptual Sending Algorithm as described
     in [RFC4861] only trigger address resolution for IPv6 addresses
     that the sender considers to be on-link.

---

>    2.  Note that Redirect Messages do not contain sufficient information
 >        to signal that an address is off-link.  Rather, they indicate a
>        preferred next-hop that is a more appropriate choice to use than
>        the originator of the Redirect.  

new: Add new paragraph and tweak the above for better transition.

      2.  It should be noted that ND does not have a way to indicate a
          destination is "off-link". Rather, a destination is assumed
          to be off-link, unless there is explicit information
          indicating that it is on-link. Such information may later
          expire or be changed, in which case a destination may revert
          back to being considered off-link, but that is different than
          there being an explicit mechanism for signaling that a
          destination is off-link.

	 Redirect Messages do not contain sufficient information to
          signal that an address is off-link.  Instead, Redirect
          Messages indicate a preferred next-hop that is a more
          appropriate choice to use than the originator of the
          Redirect. ...

---

>    3.  IPv6 also defines the term "neighbor" and "link" to refer to

s/and "link"//

It reads incorrectly in the current sentence. Changing it to "on-link"
(was that the original intention?) is also not quite right since 
"on-link" is a property of an IP address and not a property of a node.

---

>    2.  In the absence of other sources of on-link information, including
>        Redirects, if the RA advertises a prefix with the on-link(L) bit
>        set and later the Valid Lifetime expires, the host MUST then
>        consider addresses of the prefix to be off-link, as specified by
>        the PIO paragraph of section 6.3.4 of [RFC4861].

Better (above is not quite right):

     2.  In the absence of other sources of on-link information,
         including Redirects, if the RA advertises a prefix with the
         on-link(L) bit set and later the Valid Lifetime expires, the
         host MUST then update its Prefix List w.r.t. to the entry. In
         most cases, this will result in the addresses covered by the
         prefix defaulting back to being considered off-link, as
         specified by the PIO paragraph of section 6.3.4 of
         [RFC4861]. However, there are cases where an address could be
         covered by multiple entries in the Prefix List, where
         expiration of one prefix would result in destinations then
         being covered by a different entry.

---

>    3.  Newer implementations, which are compliant with [RFC4861] MUST
>        adhere to the following rules.  Older implementations, which are
>        compliant with [RFC2461] but not [RFC4861] may remain as is.  If
>        the Default Router List is empty and there is no other source of
>        on-link information about any address or prefix:

Better:

    3.  Implementations compliant with [RFC4861] MUST adhere to the
        following rules. If the Default Router List is empty and there
        is no other source of on-link information about any address or
        prefix:

---

>    This document addresses a security concern present in [RFC4861].  As
>    a result, the last bullet of the on-link definition in [RFC4861] has
>    been retracted.  US-CERT Vulnerability Note VU#472363 lists the
>    implementations affected.

s/last/last two/

     Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Dec 2009 15:09:14 -0600

Erik and Thomas,

Thanks for the review and the text - humble apologies for the delay.  I
and Wes discussed your reply.  Please see in line below between <hs> and
</hs>.  We will post a -07 soon taking care of these comments from you.

Hemant & Wes

-----Original Message-----
>From: Erik Nordmark [mailto:[email-masked]] 
>Sent: Tuesday, December 08, 2009 1:43 PM
>To: IPv6 Maintenance WG; Wes Beebee (wbeebee); Hemant Singh (shemant)
>Cc: Thomas Narten
>Subject: Editorial comments on draft-ietf-6man-subnet-model-06

>    1.  The original Neighbor Discovery (ND) specification [RFC4861]
was

>        destinations that are on-link; such Redirects update the

<hs> Agree with new text.
</hs>

<hs> The reason we worded the text this way was to point out incorrect
implementations like BSD that had combined the ND-cache with the
Destination Cache and suffered from problems in on-link determination as
a result.  We could change the text to include the Prefix List, the
Destination Cache, the Default Router List, and Neighbor Cache.  You
see, once the next-hop determination is made, to forward a packet out,
the node has to look up the entry in the Neighbor Cache for the
link-layer address.  However, if we wanted to talk just about Layer 3
information, we could include just the Prefix List, the Destination
Cache, and the Default Router List. 
</hs>

>misquote should be fixed.

<hs> Good catch - will remove the extra hyphen.
</hs>

<hs> Good catch, this should read "Destination Cache", not "Neighbor
Cache".  However, please note that the last sentence of this paragraph
should remain as "Neighbor Cache".
</hs>

>    deriving the netmask from the class of the address.

<hs> New text is fine by us.
</hs>

>    are considered to be on-link by that host.

<hs> New text is fine by us.
</hs>

>     where a node considers an address to be on-link.

<hs> Agree with new text provided "node" in new text is changed to
"host".
</hs>

>    in [RFC4861] only trigger address resolution for IPv6 addresses
that

>     that the sender considers to be on-link.

<hs> New text is fine by us.
</hs>

>          appropriate choice to use than the originator of the

<hs> New text looks great.
</hs>	

>"on-link" is a property of an IP address and not a property of a node.

<hs> Agree - removing "and link". 
</hs>

>    2.  In the absence of other sources of on-link information,
including

>         being covered by a different entry.

<hs> Agree with new text subject to changing "w.r.t. to" to "with
respect to".  Prefix list entries can overlap as you pointed out.
</hs>

>        is no other source of on-link information about any address or

<hs> Agree to new text.
</hs>

>s/last/last two/

<hs> Agree to change.
</hs>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Dec 2009 16:42:14 -0500

Hi Hemant.

It seems we have agreement on all but one point. Great!

See below.

> Cache, and the Default Router List.=20
> </hs>

I prefer the latter option, i.e., just adding "default router list" to
the first sentence.

The reason is that (going back to Section 5.2 of RFC 4861), for the
purposes of on-link determination, one doesn't use the Neighbor
Cache. One need only perform next-hop determination (which leads to a
Destination Cache Entry). At that point, if the next hop address in
the selected entry matches the address in the packet, you know its
on-link.

> should remain as "Neighbor Cache".

Yes, I agree.

> <hs> Agree with new text provided "node" in new text is changed to

OK.

> respect to".  Prefix list entries can overlap as you pointed out.

Agreed.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Dec 2009 09:29:09 -0600

>From: Thomas Narten [mailto:[email-masked]] 
>Sent: Tuesday, December 22, 2009 4:42 PM
>To: Hemant Singh (shemant)
>Cc: Erik Nordmark; IPv6 Maintenance WG; Wes Beebee (wbeebee)
>Subject: Re: Editorial comments on draft-ietf-6man-subnet-model-06

>the selected entry matches the address in the packet, you know its

Fine.  Does new text below work for you?  

OLD TEXT

The conceptual sending algorithm of [RFC4861] defines a Prefix List and
Neighbor Cache.  The combination of Prefix List and Neighbor Cache form
what many implementations consider to be the IP data forwarding table
for a host.

NEW TEXT

The conceptual sending algorithm of [RFC4861] defines a Prefix List,
Destination Cache, and Default Router List.  The combination of Prefix
List, Destination Cache, and Default Router List form what many
implementations consider to be the IP data forwarding table for a host.

Thanks,

Hemant

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Dec 2009 10:31:56 -0500

Works for me.

Thomas

"Hemant Singh (shemant)" <[email-masked]> writes:

> >From: Thomas Narten [mailto:[email-masked]]=20

> Fine.  Does new text below work for you? =20

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Dec 2009 09:38:46 -0600

Great, thanks!

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, December 23, 2009 10:32 AM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; IPv6 Maintenance WG; Wes Beebee (wbeebee)
Subject: Re: Editorial comments on draft-ietf-6man-subnet-model-06

Works for me.

Thomas

---

From: Christian Huitema <[email-masked]>
Date: Thu, 24 Dec 2009 21:14:49 +0000

This draft addresses a clear failure mode: a host believes that a destination is on-link when in fact it is not, resulting in failure to communicate. That's good. However, I have some doubts about one of the recommendations:

Strictly implemented, this means that if a local router fails, then hosts on the same link will stop communicating, when in fact they should. In other words, this rules introduce fate sharing between local connections and the local router. I don't think this fate sharing is desirable.

-- Christian Huitema