I'm a bit late into this debate. I just want to point that some time ago, we worked in the idea of the OS to be able to detect the best path, when IPv6 and one or several transition mechanisms are available. Here is the last version of the document: http://tools.ietf.org/html/draft-palet-v6ops-auto-trans-02 At that time, v6ops considered that it was not an interesting work ... So me be is time to revive it ? Regards, Jordi > From: Mark Andrews <marka@xxxxxxx> > Reply-To: <marka@xxxxxxx> > Date: Fri, 25 Jun 2010 11:01:53 +1000 > To: <ietf@xxxxxxxx> > Subject: Re: The IPv6 Transitional Preference Problem > > > In message <AANLkTiknLr5c5nKc8ewWvi9-H1ZmvQybMFArReRj7h_3@xxxxxxxxxxxxxx>, > Phil > lip Hallam-Baker writes: >> Nah, the service provider tells the client what to use via SRV records. >> >> In most cases the service provider is going to know if IPv4 or IPv6 is going >> to work better. They use different DNS names for the v4 and v6 interfaces >> and prioritize them accordingly. >> >> In most cases though the server is going to be IPv4 only or have equally >> good IPv4 and IPv6. >> >> On the client end the client is going to have a consistently better >> experience with v4 or v6. And that information can be used to inform the >> choice when making future connections. > > With well connected clients. For clients with connectivity problems > it can matter. > >> The only case where I can see a client preferring IPv6 over 4 is when they >> are behind a super-NAT and the v4 service is degraded. Or when they are >> attempting to accept an incoming connection for VOIP or video conferencing. > > Super-NAT's will become common place. > > You also want to prefer IPv6 over IPv4 so that one can see when you > can stop supporting IPv4 by looking at the traffic levels. Code will > be used for decades after it is written. You need to write code for > the end state even if it is painful at the beginning. > >> The key is to take the decision out of the hands of the application software >> so that it can be taken by the platform and allow the experience from one >> connection to be used to inform the choice made on the next. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf