Re: [v6ops] Operational Consensus on deployment

["Heatley, Nick" <[e-mail]>]

If I may stick my neck out.

I’d like v6ops to consider at least two items:

1.       (Carrier Grade) NAT64 vs NAT44 – a deathmatch.
IMHO NAT64 should be greater or equal to NAT44 when implemented correctly.
Only NAT64 can help with both private and public IPv4 exhaustion. (Note: In cellular networks, where NAT is prevalent, private exhaustion is a big issue today, driving IMS toward IPv6-only, and data services to 464xlat).
And as highlighted below, a major proportion of traffic goes pure IPv6, reducing the load on the NAT.
Why do some people still fear NAT64 or think that NAT44 is going to move them forward? MTU issues can be fixed. 64 ALGs can matched 44. I’ve even fixed FTP issues. Literals can be fixed at the host.
Holding on to the NAT44 architecture whether in Dual Stack+NAT44 or otherwise will keep us all in the old world. If you are a large ISP thinking about public exhaustion, and your plan is to introduce privates + NAT44, then think on, perhaps you are just exchanging one exhaustion date for another.
As it stands we don’t have a consensus here.


2.       A paper to update RFC6586 about the experiences of PCs and Mobile devices on 464xlat networks

It seems about the right time for this. RFC6586 left us with some cliff hangers. Does 464xlat finish the job off? Yes or no? Where are the gaps? (“Lossy and brittle” for IP literal destinations, what does this mean?)

What is the common theme of the above?
I have seen this written in the abstract for sunset4.

   Sunsetting IPv4 refers to the process of turning off IPv4
   definitively.  It can be seen as the final phase of the migration to
   IPv6
I don’t think the world is ready for sunsetting IPv4, it appears an academic topic to many. I don’t think in v6ops we are quite ready for this final phase off turning off IPv4 “as a service”.
However I do think there is some gap to bridge in v6ops, some intermediary phase between where we are now (stuck in equilibrium with IPv4 dominant), and a point where v6 is the dominant address family on hosts.

So the theme would be “v6 dominant”, and in it would be the exhaustion beating technologies, the technologies that the IETF should champion because before we can even consider turning off v4 we need to get to state where the IPv6 address at the client/host is the dominant address family for connectivity.
Let’s face it, if you have a nice stockpile of public IPv4, you may not need to care about IPv6, and dualstack might even look like some radical approach.
Everyone else needs to collectively deal with exhaustion.
I do think we have a lot to do to get our collective story straight on this.
I think papers above would help. There might be more address saving techniques to add to the list for “experience” documents, perhaps?
New ideas here? If every Client OS had some inbuilt function to allow it to function when the network can only provide it an IPv6 prefix then what would that be? Could it remain dormant until required…
Thoughts?
Regards,
Nick


From: v6ops [mailto:[e-mail]] On Behalf Of Lorenzo Colitti
Sent: 07 August 2014 14:13
To: Ca By
Cc: Tore Anderson; IPv6 Ops WG
Subject: Re: [v6ops] Operational Consensus on deployment

On Thu, Aug 7, 2014 at 10:06 PM, Ca By <[e-mail]<mailto:[e-mail]>> wrote:

> >I think it is safe to say that providing good IPv4 service is the most
> >important requirement. In many cases, it is perfectly fine to not provide
> >any IPv6 if it cannot be provided at reasonable cost / performance.
>
> Is that safe to say?

No.

20% of my subscribers are ipv6-only and for them the majority of the traffic is ipv6. For these subscribers, it is quantitatively most important that ipv6 works. Qualitatively, it is most important the most impactful services like facebook, google, and netflix work on ipv6.
Right. An operator cannot afford not to provide IPv4, because "that's not Internet". But if the majority of traffic is IPv6, then the operator can provide proportionally lower quality of service to IPv4 without disrupting user experience.

A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's only used for 5% of traffic, then the operator might just say, "Who cares? I don't; and if somebody else does, they're free to use IPv6."

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW