Subject: onlinkassumption-00 comments

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Nov 2003 14:24:39 +0200 (EET)

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

---

From: "Chirayu Patel" <[email-masked]>
Date: Sun, 16 Nov 2003 06:35:27 +0530

On Sat, 15 Nov 2003 14:24:39 +0200 (EET), "Pekka Savola"
<[email-masked]> said:

> RETRANS_TIMER .. remember that the last retransmission attempt has to
> time out as well before giving up ?

There is no delay before sending the first one, and for each NS
(MAX_MULTICAST_SOLICIT in number) there is a RETRANS_TIMER wait. Hence,
it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER).

CP

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 08:18:45 +0200 (EET)

> it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER).

I mean, there has to be some delay after sending the first address 
resolution request (before the first retransmit).

So the delay after initiating the retransmissions is 3 seconds, but there 
should be some delay before that as well, yes?

---

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 17 Nov 2003 12:51:39 +0530

On Mon, 17 Nov 2003 08:18:45 +0200 (EET), "Pekka Savola"
<[email-masked]> said:
> > >    on-link until at least address resolution has failed, which is
> > >    no less than three seconds (MAX_MULTICAST_SOLICIT *
> > >    RETRANS_TIMER)
> > >
> > > RETRANS_TIMER .. remember that the last retransmission attempt has
> > > to time out as well before giving up ?
> >
> > (MAX_MULTICAST_SOLICIT in number) there is a RETRANS_TIMER wait.
> > Hence, it will be (MAX_MULTICAST_SOLICIT * RETRANS_TIMER).
>
                ^^^^^^^^^^^^^^^^^^^^

The only delay will be for processing i.e. table lookup etc, and not a
timer based delay. It will be negligible when compared to RETRANS_TIMER.

So, for all practical purposes the aggregate delay will be
(MAX_MULTICAST_SOLICIT * RETRANS_TIMER).

> So the delay after initiating the retransmissions is 3 seconds, but
> there should be some delay before that as well, yes?

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 12:26:15 +0200 (EET)

> > I mean, there has to be some delay after sending the first address

Ok, we were talking past each other.  I thought MAX_MULTICAST_SOLICIT was 
the number of _retransmissions_, but it already seems to include the first 
solicitation (which is not a retransmission but the original 
solicitation).. so we agree.

---

From: Sebastien Roy <[email-masked]>
Date: Mon, 17 Nov 2003 16:37:57 -0500

> substantial

Agreed.

> 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

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

Ok.

> semi-editorial

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.

> picking one etc.  -- doesn't really work!

Good point, I'll add that in.

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

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

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

> mode of xml2rfc (if that's what you're using).

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

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

Agreed.

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

Agreed.

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

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.

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

O.k.

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

Yes, that makes it more clear.

Thank you,
-Seb

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 00:31:02 +0200 (EET)

Hi,

Just responding to a few comments which were maybe still a bit unclear..

> Neighbor Discovery with these suggestions?

Sorry for being unclear.. wrote up the comments too fast I guess.

My point was that as RFC2461 has been Draft Standard since 1998, there are
a lot of implementations out there with the previous behaviour.  We
(probably) can't just go and remove every references to it, like it never
existed.  We'd probably need to add a very short summary (what has
changed, and why) and discussion in ND2461bis and a pointer to this
document.

What I was saying that we could either spell the issue in more detail at 
this phase in this document, or wait until IPv6 WG resolves RFC2461bis 
issue (assuming that'd be done soon), and look what kind of text to copy 
from there to over here..

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

First, I was not sure which issue you were referring to.  The VPN scenario 
described in the v6onbydefault document, or something else?  In any case, 
at least a couple of lines would be useful :-)

> they were configured. They were then plugged in back-to-back.

Ok.  Maybe reword the first sentence to:

    For
    example, consider the case where two systems on separate links are 
    manually configured with global addresses and are then plugged in 
    back-to-back.

maybe that would be a bit easier-to-read sentence?