Subject: RE: dual stack & IPv6 on by default

From: "Bound, Jim" <[email-masked]>
Date: Sun, 9 Mar 2003 21:19:36 -0500

>Ok, I agree that this would be the common case in an IPv6 only 
>network. If a random dual stack box that has IPv6 enabled is 
>placed in a random network out there, the common case today is 
>that it has no IPv6 default router, and this ND rule would be 
>problematic for it.  That's what we were trying to get across 
>in this section of the draft.  I suppose we need to more 
>explicitly specify in the draft what types of networks we're 
>concerned with.

The worst case scenario would be 1 node coming up on IPv4 network with
IPv6.  But then it would have to use transition mechanism to speak IPv6.
Selecting the best method based on the policy of the network
administrator I will assume here.  

Is this a fairly good synopsis of your general concern within this
draft?

>
>> >   Quickly notifying the application that there's no route to the 
>> > destination so that the user can correctly configure 
>routes (on-link 
>> > or off) seems better than sitting there for minutes while 
>TCP times 
>> > out the larval connection.
>> 
>> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort 
>> immediately when ND determines that the destination is 
>unreachable, so 
>> TCP does not incur any additional delay here.
>
>Is that stated somewhere (it should be)?  Should it be 
>explicitly stated in the nodes requirements?  In practice, I 
>don't think many TCP implementations do this correctly (or as 
>you've described), and they should be fixed.

I believe from my knowledge most TCP implementations do this correctly.
The above rule is very well known by TCP implementers it has nothing to
do with ND or IPv6.  With all the specs and all the work why must we
continue to put in specs what is already a defined process that is well
defined.

>  Even if TCP is 
>fixed to abort connections, there is still a 3 second delay in 
>IP while NUD is being performed, which may or may not be 

That depends on how NUD cache was built.  Your making an implementation
judgement not a standards judgement.  Also how one builds the NUD in the
ND spec is a "conceptual" model not a required model just that the state
changes are in fact supported.  For all any of us know most have figured
this out to avoid a 3 second delay and its down to 300 nanoseconds. 

If you want an optimization you should suggest one so we can discuss. 

>acceptable depending on how many IPv6 destinations the 
>application will try before trying IPv4.  

And some applications will never try IPv4 because they are not using
IPv4 anymore for this application.  We cannot assume in the logic
premises for this discussion that ALL applications can just use IPv4
that is an invalid assumption I believe.  And an incorrect way to solve
IPv6 node "perceived" problems.

>I can't see this as 
>being acceptable when a destination resolves to a few dozen 
>IPv6 addresses, for example.

Your speaking of the route above?  Or because of multiple DNS entries?

>  An immediate ICMP destination 
>unreachable/network unreachable from IP would be generated if 
>it didn't assume destinations were on-link.

So you can't send to nodes not on the same link using host routes? This
is very possible?

Thanks
/jim

---

From: Sebastien Roy <[email-masked]>
Date: Mon, 10 Mar 2003 11:31:07 -0500

> Is this a fairly good synopsis of your general concern within this

I'm not sure if I parsed what you wrote above correctly, so I can't say
for sure.  Just to make sure we're on the same page; The general concern
being addressed by this draft is that enabling IPv6 on a dual-stack node
in an IPv4 network that may or may not have IPv6 routing support might
result in side-effects that the user of that node didn't anticipate or
welcome.  Some of those are protocol related (ND, ICMPv6, TCP, etc...),
and others are administrative.

> continue to put in specs what is already a defined process that is well

It could very well be that the behavior is well defined to a number of
people, and implemented as such in many TCP implementations.  How it
became well defined is a mystery to me, because RFC 1122 actually
suggests (in section 4.2.3.9) to do the opposite of what makes sense in
this situation.  It says that if TCP receives an ICMP destination
unreachable code 0 (no route to destination) or 1 (host unreachable),
that it MUST NOT abort the connection.  That's in direct conflict with
what we're all agreeing is the right thing to do here (to abort the
connection if it's in SYN-SENT or SYN-RECEIVED state).

> this out to avoid a 3 second delay and its down to 300 nanoseconds. 

I agree that it's a conceptual model.

> If you want an optimization you should suggest one so we can discuss.

My suggested optimization is that you don't assume a destination is
on-link just because you don't have a default route.

> IPv6 node "perceived" problems.

True, IPv6-only applications won't have these problems.  

> Your speaking of the route above?  Or because of multiple DNS entries?

I'm trying to say that if you're assuming that all destinations are
on-link because you don't have a default route, as a name resolves to
more IPv6 addresses, the delays associated with failed NUD on each
address are compounded.

> So you can't send to nodes not on the same link using host routes? This

Absolutely, and that's exacly my point.  If you have a host route (or
any other route that covers the destination), use it.  If you don't have
a route, then the destination is unreachable.

If you don't have a route to the destination, why try to reach it
on-link just in case the destination might happen to be on-link?  Is
there a situation where this would be useful?

-Seb