onlinkassumption-00 comments

[Pekka Savola <pekkas@netcore.fi>]

substantial
-----------

1) I believe the document should try to say more clearly in which practical
scenarios this problem at least surfaces at, like in the abstract (and
similar in the introduction):

   This document proposes a change to the IPv6 Neighbor Discovery
   conceptual host sending algorithm.  According to the algorithm, when
   a host's default router list is empty, the host assumes that all
   destinations are on-link.

to:

   This document proposes a change to the IPv6 Neighbor Discovery
   conceptual host sending algorithm.  According to the algorithm, when
   a host's default router list is empty, the host assumes that all
   destinations are on-link.  This is particularly problematic with
   IPv6-capable nodes which do not have IPv6 connectivity, e.g., a default
   router.

2) this is not so relevant for this particular draft, but maybe for the
generic on-by-default document:

   The unreachability determination for a destination as it pertains to
   this rule is an implementation detail.  One implementable method is
   to do a simple forwarding table lookup on the destination, and to
   deem the destination as reachable if the lookup succeeds.

==> the interesting question is, how would this work without an on-link
assumption?  For example, if default route would exist, but the router would
go down, would a destination be considered unreachable if the Neighbor
Discovery goes into a state where it's clear the destination is not
reachable?   For that matter, I wonder how that info would be passed down to
getaddrinfo in libc in any case... :-/

3) The SEND threat could very well be moved under section 3 as a subsection
of its own?

semi-editorial
--------------

   on-link until at least address resolution has failed, which is no
   less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER)

==> isn't this four seconds, i.e., (MAX_MULTICAT_SOLICIT + 1) *
RETRANS_TIMER .. remember that the last retransmission attempt has to time
out as well before giving up ?

   2.  Attempt to resolve the destination on every link.

   If the destination is indeed on-link, the first option may not
   succeed since the wrong link could be picked.  The second option
   would always succeed in reaching the destination (assuming that it's
   reachable) but is more complex to implement.

==> the good question would be what would happen if the address was resolved
on two links and there was a response from both!  duplicating the packet,
picking one etc.  -- doesn't really work!

4. Conclusion

==> instead of just deleting everything related to the on-link assumption,
it may be reasonable to suggest some summary of the problems or that in
previous versions of the specification, the behaviour was different..  But
that's likely to be ironed out with IPv6 WG.

...

5. Security Considerations

   VPN case

==> does this (the cisco vpn issue?) need more elaboration here?


editorial
---------

==> there are so many empty lines here, so I suggest using the "compact"
mode of xml2rfc (if that's what you're using).

Internet-Draft             On-Link Assumption                August 2003

==> I'd use a bit longer "Short name", like "On-Link Assumption Harmful"

2. Background

==> s/Background/Background to the Onlink Assumption/

 For
   example, two systems that are manually configured with global
   addresses while on separate links are then plugged in back-to-back.
   They can still communicate with each other via their global addresses
   because they'll correctly assume that each is on-link.

==> is there something missing after "while ..." -- I can't quite parse
this?

   least one reachable IPv4 address, the delay associated with NUD of

==> s/NUD/Neighbor Unreachability Detection (NUD)/

4. Conclusion

==> s/Conclusion/Proposed Changes to RFC2461/ ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings