Re: onlinkassumption-00 comments

[Sebastien Roy <Sebastien.Roy@Sun.COM>]

pekkas@netcore.fi wrote:
> 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.

Agreed.

> 
> 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?

I suppose not since the default route isn't removed until the router
lifetime expires.  That's a drawback to this approach, it's subject to
the effective maintenance of the forwarding table.  There might be a
better way of doing rule 1, this was one example.

> For that matter, I wonder how that info would be passed down to
> getaddrinfo in libc in any case... :-/

That's an implementation detail.  I can think of a number of ways of
doing it, one of which is described in the 1st paragraph of section 8
in rfc3484.

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

Ok.

> 
> 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 ?

I believe this issue has already been addressed.  For completeness,
here's the text from rfc2461 section 7.2.2:

   If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
   solicitations, address resolution has failed.  The sender MUST return
   ICMP destination unreachable indications with code 3 (Address
   Unreachable) for each packet queued awaiting address resolution.

> 
>    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!

Good point, I'll add that in.

> 
> 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.

I'm not sure I completely understand the problem you're bringing up.  Are
you worried that the conclusion won't make sense once the IPv6 WG updates
Neighbor Discovery with these suggestions?

> 
> 5. Security Considerations
> 
>    VPN case
> 
> ==> does this (the cisco vpn issue?) need more elaboration here?

I don't have objections to elaborating.  What do you think would be
useful?

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

Yes, that's how I generated the drafts.  I'll try the compact mode.

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

Agreed.

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

Agreed.

> 
>  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?

I don't think so.  Removing the cosmetic bits in the sentence boils it
down to: "two systems that are configured while on separate links are
then plugged in back-to-back".  While they were on separate links,
they were configured. They were then plugged in back-to-back.

> 
>    least one reachable IPv4 address, the delay associated with NUD of
> 
> ==> s/NUD/Neighbor Unreachability Detection (NUD)/

O.k.

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

Yes, that makes it more clear.

Thank you,
-Seb