[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
==> this spec needs at least an IANA Considerations section, stating at
1) the allocation guidelines for ND option types/codes (Standards Action?
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
==> 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
==> 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
- 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.
- 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
A Neighbor Advertisements that passes the validity checks is called a
==> 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
- 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 ?
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