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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
