Code will be used for decades which is why IPv4 will always be with us.
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(_at_)isc(_dot_)org> wrote:
In message
<AANLkTiknLr5c5nKc8ewWvi9-H1ZmvQybMFArReRj7h_3(_at_)mail(_dot_)gmail(_dot_)com>,
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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf