>> 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 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
