ietf
[Top] [All Lists]

Re: The IPv6 Transitional Preference Problem

2010-06-24 18:49:18

In message <14D6DC7C-FCD2-4EB9-AA56-ECF13A110C33(_at_)virtualized(_dot_)org>, 
David Conrad
 writes:
Martin,

On Jun 23, 2010, at 6:06 AM, Martin Rex wrote:
What you described results in a negative incentive for servers to
become accessible under IPv6 as an alternative to IPv4.  That is a real pro
blem.

I guess I'm not seeing how it is a significant negative incentive to servers.

If IPv6 connectivity is still bad, then the connection request will
not reach the server and the server will not notice.  

Right.  So, the only case where a parallel open would potentially have any im
pact on the server is when there is good v6 connectivity.  Presumably, if a s
erver operator has configured v6, they are anticipating v6 load and will have
 engineered for that load.  Since for any given session, the application will
 either communicate via v4 or via v6, not both, the additional load on the se
rver will be exactly one additional communication initiation event.  I honest
ly have difficulty seeing a server operator building a system so close to the
 edge that this would be a real concern, particularly given any server connec
ted to the Internet today is going to be subject to vastly more load due to r
andom scans from malware.

In the serial case, there are two options: v4 first or v6 first.  If v4 is ch
osen first, it is unlikely v6 will ever be used, thus the server operator set
ting up v6 would be a waste of time.  If v6 is chosen first, then the client 
will have to wait for the v6 initiation to time out in the case of bad v6 con
nectivity.  My guess is that this would result in an increase in support call
s to the server operator ("why is your server so slow?") with the typical sup
port center response being "turn off v6 support".  I believe this has been em
pirically demonstrated.

The third choice is to do a non-blocking connect to IPv6 then if that does
not succeed in 1 or 2 seconds (most successful connects are within this
peroid but connect failures are considerably longer) initiate a non blocking
IPv4 connection and keep whichever completes first and abort the other.
 
I personally don't see how we'll get anywhere with v6 deployment using the se
rial approach nor do I see any other options than parallel vs. serial.  Since
 you believe parallel open to be a problem, what is your proposed alternative
?

Regards,
-drc



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf