Subject: [sunset4] FW: Call for Agenda Items

From: "George, Wes" <[email-masked]>
Date: Fri, 13 Jul 2012 20:36:13 -0400

Folks, the authors of 464xlat have requested that we consider their draft. We're getting feedback that it's not a good fit in v6ops, and may be more appropriate here. Please review and comment. The answers to our questions are below, and are a good example of what we're looking for in terms of justification.

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-05

Thanks,

Wes

-----Original Message-----
From: Byrne, Cameron [mailto:[email-masked]]
Sent: Friday, July 13, 2012 8:46 AM
To: Fred Baker (fred); MAWATARI Masataka
Cc: Marc Blanchet; George, Wes; [email-masked] jaeggli; Ron Bonica; Ron Bonica; [email-masked]; Ralph Droms
Subject: RE: [sunset4] Call for Agenda Items

1) describe the problem to be solved and show that there is widespread demand for a solution

Problem = Fast growing edge networks require IPv4 service but IPv4 addresses are not available.  IPv6-only service, including in combination with NAT64/DNS64, is not a sufficient consumer offering since many applications (including Skype) require IPv4 because they use IPv4 literals in their signaling or make IPv4-only socket calls. Thus, these applications require IPv4.  Our approximation is that 15% of application in the Android market require IPv4 and do not work without it.

Further description of why IPv6-only is not sufficient here http://tools.ietf.org/html/rfc6586

We believe the list traffic on this topic has shown widespread demand (T-Mobile USA, T-Mobile CZ, Rogers, TW Cable, BT, and representatives from other service providers have noted on-list that this solution has value ... and Android open source implementation is available and a commercial solution from NEC)

2) demonstrate that the problem cannot be solved with existing technologies

There is no available solution today, aside from the implementations of 464XLAT, that allow an Android phone with an IPv6-only connection (with or without NAT64/DNS64) to make a Skype call or stream a Netflix movie.

MAP solutions are in an adjacent space but are not acceptable for the following reasons.

First, they require static port mapping.  The static port mapping is not as efficient as stateful dynamic NAT, especially given that port overloading can allows 1 IPv4 address to source 100s of thousands of NAT64 connections.  For example, how many IPv4 addresses would it take to launch a new LTE service for 20 Million customers?  At 1024 ports per customer? ... those address are not feasible to get without great expense with a MAP static mapping.

Second, it is not possible for an existing service provider, who by RIR policy is required to be at least 80% deployed from their IPv4 reserves ... to launch MAP.  Meaning, if I have the vast majority of my addresses deployed, it would not possible to easily move my deployed addresses into a MAP pool.  This is especially the case for operators that already have  stateful CGN, moving to less address efficient MAP is not feasible with limited addresses.

Finally, MAP requires DHCPv6.  This is not available in 3GPP networks (GSM / UMTS / LTE )

"Stateful DHCPv6-based address configuration [RFC3315] is
   not supported by 3GPP specifications."

http://tools.ietf.org/html/rfc6459

3) provide a description of the proposed solution along with its impact on current IPv4-only use and justification that it does not harm or delay the deployment of IPv6

First, IPv6 access networks are a pre-requisite for the 464XLAT architecture, the architecture is explicitly made to enhance and expedite the effectiveness of IPv6-only networks.  Also, from a network provider perspective, translation traffic cost more to operate, so the SP will be incented to encourage IPv6 native traffic.

Description from the abstract:

    This document describes an architecture (464XLAT) for providing
   limited IPv4 connectivity across an IPv6-only network by combining
   existing and well-known stateful protocol translation RFC 6146 in the
   core and stateless protocol translation RFC 6145 at the edge. 464XLAT
   is a simple and scalable technique to quickly deploy limited IPv4
   access service to IPv6-only edge networks without encapsulation.

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.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 Jul 2012 19:15:40 -0700

It is worth noting in case there isn't 100% overlap in the list 
subscriptions (seems unlikely I know) that there is a rather long 
history on the v6ops list which can be cruised through the archive.

On 7/13/12 5:36 PM, George, Wes wrote:
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4
>