Re: [sunset4] New draft: draft-kaliwoda-sunset4-dual-ipv6-coexist

["George, Wes" <[e-mail]>]

Hello Kali-

I think that this draft brings up some good topics for discussion.

Speaking first as a WG chair, part of me thinks that this might be appropriate as something that is integrated into the gap analysis that is already in progress (draft-ietf-sunset4-gapanalysis). However, since our gap analysis thus far has focused more on actually disabling IPv4 and the problems that come with that, rather than in this transition area where you are still technically operating a dual-stack network, it might be appropriate as a either a standalone document, or as a part of a larger gap analysis of the late steps of the transition phase (i.e. as the SP tries to start moving towards disabling IPv4 altogether and has at least some IPv6-only devices on the network). I'd like some comments from the WG about which way they see being more useful.

Now as an individual:
I think rather than this being simply a problem statement, I'd rather see it as a gap analysis and informational discussion that talks about what things an SP can do to influence the client's choice today, and what things (if any) may be missing to do this cleanly without adverse impact to other hosts.
From a scoping perspective, I think we have two cases we need to care about: dual-stack devices operating in an IPv6 + IPv4 NAT/CGN, and true single-stack IPv6 devices. In order to get to single-stack, the SP needs to be able to start moving dual-stack devices to use more and more IPv6, and part of that is to use less and less IPv4, possibly even as a test to see if the 6to4 translation is working well enough to turn off IPv4. Then there is the subcase you mention about whether or not separate DNS server IPs are used for different services/address-families or not.
Each of these cases, plus the implementation that the carrier has chosen as far as NAT, ALGs, and other details will affect which is the preferred destination that will lead to the best use of the carrier's resources and more importantly, the best customer experience. It'll also potentially interact with happy eyeballs. I'm not sure that simply assuming that the method of transport for the DNS is going to be enough to determine the behavior in an environment with a separate DNS server IP for DNS64. What if the host sends out A and AAAA records in parallel over IPv4 and IPv6 transport, respectively? How does it determine whether it should use IPv4 or IPv6-translated-IPv4? Happy eyeballs? Is that enough to make the right decision? You already mention the possibility of using different DNS server IPs for different services, and it might make sense to discuss this in more detail, pros/cons, implications, etc.

So if we're going to discuss this, we probably need to be thinking in terms of whether we need additional intelligence in happy eyeballs to detect these scenarios and make a choice, or even a method to signal what class of service (native, NAT, or 64translated) is available so that the host or application can make a better decision about which stack to use. There was considerable debate during the last revision of happy eyeballs about the appropriateness of inducing a delay on one stack or the other in order to manipulate the choice that happy eyeballs makes. At the time, it was focused on compensating for minor differences in latency between IPv4 and IPv6 such that HE wouldn't prefer IPv4 unnecessarily. But perhaps at a certain point that artificial manipulation actually makes some sense, not as a way to handicap IPv4 to spur IPv6 usage, but as a way to ensure that the most appropriate address family is chosen based on what the SP has implemented - in other words, use latency as a hint to direct HE-capable devices at the best method to reach their intended destination.


Thanks,

Wes George


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Arkadiusz Kaliwoda (akaliwod)
> Sent: Thursday, September 13, 2012 6:04 PM
> To: [e-mail]
> Subject: [sunset4] New draft: draft-kaliwoda-sunset4-dual-ipv6-coexist
>
> Hi All,
>
> I have submitted a new draft “draft-kaliwoda-sunset4-dual-ipv6-coexist”
> that defines a problem of introducing IPv6/IPv4 translation service in
> IPv6 enabled network. I think this problem will have an impact on the
> transition from IPv4 to IPv6.
>
> IMHO today many operators are focused on adding IPv6 support in their
> network including access network and CPEs, in order to provide dual
> stack data service for their customers. Service Providers are also very
> much concerned on handling the IPv4 exhaust problem, especially when the
> number of subscribers thus hosts in the network keeps on increasing
> fast. Once these challenges are under control and as soon as more
> consumer devices are IPv6-ready, the process of sunsetting IPv4 will
> start for good. Not only in the SP network where 4over6 technologies are
> of key importance and where this transition has already started in some
> cases. More importantly in the context of this draft, the transition
> from IPv4 or dual-stack to IPv6-only will also start in the end hosts.
> If such transition starts sooner, of it has already started, then I
> think it makes the identified problem even more interesting and
> important.
>
> I hope you will find the problem defined in the draft valid and relevant
> to the scope of SUNSET4 Working Group.
>
> Please find the links to the document and abstract below.
>
> Thank you for review of the draft and your comments.
>
> Regards
> Kali
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, September 12, 2012 9:43 PM
> To: Arkadiusz Kaliwoda (akaliwod)
> Subject: New Version Notification for draft-kaliwoda-sunset4-dual-ipv6-
> coexist-00.txt
>
>
> A new version of I-D, draft-kaliwoda-sunset4-dual-ipv6-coexist-00.txt
> has been successfully submitted by Arkadiusz Kaliwoda and posted to the
> IETF repository.
>
> Filename:      draft-kaliwoda-sunset4-dual-ipv6-coexist
> Revision:      00
> Title:                 Co-existence of both dual-stack and IPv6-only hosts
> Creation date:         2012-09-12
> WG ID:                 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-kaliwoda-
> sunset4-dual-ipv6-coexist-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-kaliwoda-sunset4-
> dual-ipv6-coexist
> Htmlized:        http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-
> ipv6-coexist-00
>
>
> Abstract:
>    Some networks are expected to support IPv4-only, dual-stack, and
>    IPv6-only hosts at the same time.  Such networks may want to add
>    IPv6/IPv4 translation for the IPv6-only host so it can access servers
>    on the IPv4 Internet.  Adding translation service to the IPv6-enabled
>    network may change dual-stack host behavior and affect the way
>    deployed network is working.  This document defines the problem
>    statement for such networks.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> sunset4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sunset4

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.