The IPv4-6 transition will inevitably take place in middleboxes. Most actual networks will use IPv4 internally and IPv6 will be an Inter-Network protocol.
Trying to code for the end state before the middlebox spec is known is futile. The end point device is going to have to work with the middlebox to work out the best choice of route. I can't see the point of piddling about with heuristic protocols when we can write a middlebox spec that tells the endpoint what to do straight off the bat.
Part of the problem here is that we have an IPv6 transition strategy that does not mesh with the DNS.
Another part of the problem is that people are trying to fit everything into the mould of end-to-end as if it was some sacred cow. E2E was a better way to design a system from scratch compared to the telephone system. Now that we have legacy systems in place we have billions of end points and similar problems of rigidity as the telco network had.
At the moment the assumption is that the DNS is not intelligent. But that does not have to be the case. If we make the service discovery mechanism consistent across protocols there is more scope for the DNS to do the right thing.
On Thu, Jun 24, 2010 at 9:01 PM, Mark Andrews <marka@xxxxxxx> wrote:
In message <AANLkTiknLr5c5nKc8ewWvi9-H1ZmvQybMFArReRj7h_3@xxxxxxxxxxxxxx>, Phil
lip Hallam-Baker writes:With well connected clients. For clients with connectivity problems
> 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.
it can matter.
Super-NAT's will become common place.
> 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.
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
_______________________________________________
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf