Re: dual stack & IPv6 on by default

[Sebastien Roy <Sebastien.Roy@sun.com>]

Jim.Bound@hp.com said:
> >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?

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.

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

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

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

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.

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

True, IPv6-only applications won't have these 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?

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.

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

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