Review input on draft-ietf-v6ops-onlinkassumption-00.txt and suggestions for next steps.
1. Introduction Neighbor Discovery for IPv6 [ND] defines a conceptual sending algorithm for hosts. This algorithm states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This assumption creates problems for destination address selection as defined in [ADDRSEL], and adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined in multihomed scenarios, and has some subtle security implications. All of these issues are discussed in this document. This entire spec is predicated on statement in 2461 that are conceptual and not required as compliance to ND RFC 2461. In fact I know multiple implementations that approached some of the specifics of this differently, which is fine as this part of ND gets into a suggestion and not an IETF compliance to the standard. Also below is the wording I think relative I provide from 2461. I also want to note the caveat stated in section 5. below where ND clearly states it is not addressing the issues of source address selection and multihomed hosts. I recall when this was added to ND and the spec in review here is exactly why it made me nervous to put it in ND, thus the lower paragraph in section 5. inroduction below my comments. I believe the L bit with prefix options is an excellent optimzation for communications for IPv6 if used correctly. That is not the issue. So I would like to suggest that the title currently of the draft "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful" is not a good reference to the problem the spec is concerned with. At a minimum it should have something like "conceptual sending algorithm" should be checked or however best to denote this spec's issue. But the current title I feel is misleading. My input to the authors and the IPv6 WG is that providing a BCP update to section 5 for address selection, and then probably a different spec for multihomed hosts is the work to be done. ND section 5 is very clear as a spec this is a "conceptual" reference and that it is specifically not to be used for address selection or multihomed hosts. See 2461 references below. >From 2461 5. Conceptual Model of a Host 5. CONCEPTUAL MODEL OF A HOST This section describes a conceptual model of one possible data structure organization that hosts (and to some extent routers) will maintain in interacting with neighboring nodes. The described organization is provided to facilitate the explanation of how the Neighbor Discovery protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host. >From 2461 5.2 Conceptual Sending Algorithm Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). If the Default Router List is empty, the sender assumes that the destination is on-link. Thanks, /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
