From: "Spencer Dawkins" <spencer@mcsr-labs.org>
Date: December 13, 2005 1:04:30 AM CEST
To: "General Area Review Team" <gen-art@ietf.org>
Cc: "David Kessens" <david.kessens@nokia.com>, "Fred Baker"
<fred@cisco.com>, <sebastien.roy@sun.com>,
<alain_durand@cable.comcast.com>, <jpaugh@speakeasy.net>, "Kurt
Lindqvist" <kurtis@kurtis.pp.se>
Subject: Gen-ART Review of draft-ietf-v6ops-onlinkassumption-03.txt
I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see http://
www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Summary: this specification is headed the right direction for
publication as an Informational RFC, but still needs some work in a
couple of places that were confusing to me (and I thought I
understood the topic).
Comments:
If I understand this document correctly, it's telling me that the
on-link assumption was put in place to allow communication between
two hosts with different global prefixes in the absence of an IPv6
router, and that this assumption causes problems (see section 3 for
details), so the assumption should be removed (see section 4 for
details). Right so far? Stop me now, or ...
- The specification is arguing for the removal of the assumption,
but doesn't ever actually say whether we just don't care any more
about communications in the absence of an IPv6 router when two
hosts with different global prefixes are on the same link, or if
there is some other mechanism that now allows this communication to
succeed without the assumption. I think I know what actually
happens, but I'm guessing. I'd just like to see this spelled out a
bit more clearly.
- Section 3.3 is a lot less clear than the other parts of section
3. It wasn't clear to me whether dropping the packet is actual
behavior in deployed hosts or not, and I wasn't sure whether
dropping the assumption fixed all the problems with multiple links
(I think it does, but I'm reading between the lines). I suspect
that the problem is that, in the absence of one defined behavior,
you're trying to describe multiple problems at once, but Section
3.3 is still confusing (that's why I'm not sure I can suggest
replacement text, beyond, "There are three things that an
implementation can do with a packet when faced with multiple
interfaces and the on-link assumption, and all of them are bad, and
only the most complex action is likely to work even most of the
time" - is that the point?)
- In section 5, I'm guessing you are telling me that the removal of
the assumption "removes all of the security-related vulnerabilities
of the protocol as described in Section 3.4", but the current text
says "removes some vulnerabilities as described", and "some" is
ambiguous.
Minor nits:
- It bothers me that an observed implementation error is used in
Section 3.4 to justify changing the protocol. I understand the
problem, but OS implementations may be broken in lots of ways,
right? Probably doesn't matter because there are so many other
justifications, but...
- Since RFC 1122 is, like, 116 pages long, it would be nice to
include the section number (4.2.3.5) in the reference at the bottom
of page 4.
I hope this is helpful - most of the text is very clear, but there
are just some places that faded out on me.
Thanks,
Spencer