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

["Arkadiusz Kaliwoda (akaliwod)" <[e-mail]>]

Hi Wes, 

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

[Kali] I am glad it is the case. Thank you.

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.

[Kali] Ok, I will wait for advice on this.

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.

[Kali] My intention was to start with the problem statement. If the problem statement is considered valid by the WG, then probably it has to be addressed, for example as the extension of this draft to evaluate the possible options that are already defined  or being worked upon or identify the need for yet another solution (if necessary).

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.

[Kali] I assume that by 'device' above you refer to consumer device behind managed CPE. I agree, we can have the mix of dual-stack and single-stack devices in the home network with the final goal of IPv6-only devices which may go through NAT64 translation path when necessary. Separate DNS server is not enough I am afraid to control the client's behavior; I was rather referring to this subcase based on the assumption that Service Provider may not be willing to modify the existing DNS server; due to operational complexity, risk mitigation or simply lack of DNS64 support on the deployed DNS server. In such case DNS64 must be on different device. But indeed, this choice may be also driven by other considerations.

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. 
[Kali] I agree. As of now, there are only two possible paths; IPv4 incl. optionally NAT/CGN or native IPv6 forwarding. Dual stack hosts may select either of the two and mechanisms like happy eyeballs, make the choice optimum for the consumer device/app. As long as it makes IPv6 traffic growing and offload NAT44 path, Service Provider may be happy but I think that very soon they will start to think "what's next". If we add stateful NAT64, then the situation becomes more challenging as I tried to explain in the draft. I think that the problem statement boils down to the fact, that SP may need to have better control or at least the means to affect the decision of device on the preferred destination and path taken through the SP network. In order to optimize resources, provide the best customer experience and ease or even allow smooth and controlled transition process to IPv6 only environment. Not sure if you agree with that... because this is not exactly what I have written in the draft but in fact this was the main incentive for me to write one.

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. 
[Kali] I think that separate DNS64 server will not be enough to determine the behavior of device. There is no control what transport is used by dual-stack hosts and probably SP cannot switch off IPv4 transport for DNS as long as there will be unknown % of IPv4-only clients or even dual-stack clients that for some reason use IPv4 DNS server only. There is also no control on what IPv6 DNS address to give to dual-stack and IPv6-only device. No control => no deterministic behavior I would risk to say.

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.
[Kali] I think that happy eyeballs selects the best/quickest path through the network. It can be IPv4, or IPv6 or IPv6-translated-IPv4 i.e. I don't think that Service Provider has much control on this process as soon as host receives synthetized AAAA answer, A answer and standard AAAA answer. I fully agree that it has to be discussed in greater details. 

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.
[Kali] I was not following very closely the previous discussions. I may not be on the right path and sharing my first thoughts on this topic. If both stacks are available and multiple DNS responses are given, it may be the host/application decision, that can be influenced by adding delay on the SP network, as long as it is the right way to influence client's behavior. I am not sure as the Service Provider I would like to leave the choice to app/host whether native/NAT/64translated path is to be selected; I am not representing Service Provider community though :) I tend to think that SP should have some mechanisms to better control what DNS response should be provided to the client device (e.g. 64translated path is only considered when the synthetized DNS response is given) or maybe which client should be using what DNS server. Followed by the additional hints (like delay) for the client devices that receive multiple responses, to influence the decision making process. 

I am not trying to say that control of every aspect of host behavior is the goal. Although if the Service Provider would consider the following strategy to migrate to IPv6:
- add native IPv6 path for dual stack and let the best one win (e.g. happy eyeballs)
- before or after; add NAT44 CGN to mitigate IPv4 exhaust problem, allocate the correct resources for it
- add DNS64/NAT64 for IPv6 only to test and promote IPv6-only path, monitor and plan for correct resources for stateful NAT64 engine
- move dual-stack devices to use NAT64 path instead of NAT44 path; re-use the CGN resources (i.e. IPv4 address pool) 
- manage the native IPv4 leftover traffic (at this stage only or mostly IPv4-only devices or when IPv4 literals are used by apps)
- plan switching off IPv4 in the SP network
Then I am wondering how it could be achieved without some ways of controlling or affecting the client devices behavior.

I would be happy to receive your feedback.

Thanks
Kali


> -----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.