IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
draft-ietf-v6ops-onlinkassumption-04
Yes
(David Kessens)
No Objection
(Allison Mankin)
(Margaret Cullen)
(Russ Housley)
(Sam Hartman)
Note: This ballot was opened for revision 04 and is now closed.
Bill Fenner Former IESG member
Yes
Yes
(2005-12-15)
Unknown
I'm glad to see documentation of design decisions (& changes thereto). I wish there was more of this, so there could be less "What were they thinking in 2005 when they removed the on-link assumption!?" in 2010 ;-)
David Kessens Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
(2005-12-15)
Unknown
!! Missing citation for Informative reference: P007 L015: [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-12-13)
Unknown
Gen-ART review will be at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-v6ops-onlinkassumption-03-dawkins.txt
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2005-12-13)
Unknown
I found Section 3.3 very hard to parse. This section, in particular: The second option might succeed in reaching a destination (assuming that one is reachable) but is more complex to implement, and isn't guaranteed to pick the correct destination. For example, there is still ambiguity about which link to use if more than one node answers the solicitations on multiple links. In previous parts of Section 3, we seemed to be dealing with a host attempting to send a packet using a known AAAA record. In this section, it's not clear whether the argument is that a host with multiple interfaces has an interface selection problem that is unresolvable because of on-link assumptions, or that the on-link assumption again causes a poor ordering of attempts to reach a host, or causes ambiguity because of non-globally unique addressing. Some clarification would probably help here.