Subject: RE: dual stack & IPv6 on by default

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Mar 2003 18:04:02 -0500

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

---

From: Alain Durand <[email-masked]>
Date: Mon, 10 Mar 2003 15:13:16 -0800

Bound, Jim wrote:

>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?
>
Alternate scenario:
We ship our system so they configure IPv6 ON by default on all interface.
User install this machine on his v4-only network and now experiment
larger than usual delays to connect to his favorite servers.
User call customer support.
This is what I worried about.

    - Alain.

---

From: [email-masked]
Date: Tue, 11 Mar 2003 12:47:40 +0900

>This is what I worried about.

	your worry has very little to do with IPv6 itself.  this is because
	of the way we operate IPv6 today (especially in the States) where
	long-haul tunnels and excessive/nonconsiderate transit is common.

	another thing is that users would call customer support regardless
	from the protocol type they're using.  IPv4 or IPv6.  there's no
	difference.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Mar 2003 08:08:21 +0200 (EET)

> This is what I worried about.

How do the delays get longer, I wonder?

Different flavors of BSD have shipped v6-enabled by default since, about
2000 or 2001, I don't remember anymore, and I've never seen anyone
complain about increased delays.

I don't think there should be any significant potential drawback *until*
the system is configured with a non-link-local address.

-- 
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: Tim Chown <[email-masked]>
Date: Tue, 11 Mar 2003 13:31:04 +0000

> would?  Is this the kind of basic mistake your also worried about?

Agreed if you're static in a network, then that's a mistake.  But a common
problem is taking an IPv6-enabled device from a "dual stack" network where 
it happily runs using either protocol into one where only IPv4 is supported.
Then what happens varies with OS/browser.   

For example, in WinXP+MSIE6 any attempt to reach a site with an AAAA (and A)
record will fail with an error after 20-60 seconds.  With WinXP+Mozilla 1.3 
a similar attempt will just get an immediate "connection refused".   In 
neither case is there (the desirable) fallback to IPv4.

So for people who want to go dual-stack in their workplace yet take devices 
to IPv4-only networks that's the problem they face.   Of course you get what 
you deserve maybe for the application writer trusting presence of a DNS 
record as an indication of connectivity.

There will be some user-land settings required for IPv6 connectivity.  For
example RFC3041 needs to be per application so you can rely on (as many 
people will want to) per-host IP-based authentication for ssh access, while
taking advantage of RFC3041 while browsing the net from the same host.
I can see that we can offer users a privacy/fixed IP toggle, and many could
understand that as an advanced setting in their TCP/IP options, but it's
something we want to shield "typical" users from.

I don't believe a userland v4/v6 toggle would be useful for "typical" users.
It be used by the v6-geeks in the current stage of deployment, but we need
more robust methods for handling movement between dual-stack and IPv4-only
networks where IPv6 is enabled on a device.   We're paying for the choice
of app developers to promote IPv6 by trying IPv6 ahead of IPv4, and then not 
falling back (quickly) when it fails.

Tim

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 11 Mar 2003 14:43:18 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi,

> larger than usual delays to connect to his favorite servers.

The user won't, because in this case the machine won't get any address
prefix and routing information.

The trouble comes when the customer's net has a long-delay IPv6 connection.

Regards,
	-is

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 11 Mar 2003 10:23:45 -0500

In message <[email-masked]>, Pekka Savola wr
>the system is configured with a non-link-local address.

There have been reports of problems with some Web browsers trying to 
use only the v6 address.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

---

From: [email-masked]
Date: Wed, 12 Mar 2003 05:45:32 +0900

>There have been reports of problems with some Web browsers trying to 

	this is due to the way mozilla is written.
	mozilla did:
		hp = gethostbyname2(host, AF_INET6);
		if (!hp)
			hp = gethostbyname(host);
	so mozilla tries to connect to IPv6/v4 dual stack destination, it
	would try to connect to IPv6 only.  it has to be fixed by using
	getaddrinfo(3).

itojun