RE: dual stack & IPv6 on by default

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

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

For edification.  I have a node on a work LAN that knows nothing of
IPv6.  I download software and configure my node to be capable of IPv6.
I manually configure my interface to support IPv6.  I now ftp to an IPv6
address.  This is not going to work.  But I was stupid to think it
would?  Is this the kind of basic mistake your also worried about?

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

But there also could be no problem is my point.  I think the draft
should state when there is no problem at all.

Showing both sides in the draft is important.

/jim
>
>> >> 
>> >> 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
>
>