RE: dual stack & IPv6 on by default

["Bound, Jim" <Jim.Bound@hp.com>]

>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