Re: IPv6 only host NAT64 requirements?

[Ca By <[e-mail]>]

On Wed, Nov 22, 2017 at 12:05 AM Alexandre Petrescu <
[e-mail]> wrote:

>
>
> Le 22/11/2017 à 01:01, Brian E Carpenter a écrit :
> > in line...
> >
> > On 21/11/2017 22:40, Ola Thoresen wrote:
> >> On 20. nov. 2017 20:37, Brian E Carpenter wrote:
> >>
> >>> On 21/11/2017 02:36, Ole Troan wrote:
> >>> ...>> [Med] These are generic statements, Ole. We are talking about
> the IETF case.
> >>>>> * The IETF has no control on the hosts that connect to the IETF
> network,
> >>>>> * IETF attendees who are using corporate devices, have no control on
> these hosts
> >>>>>
> >>>>> So, how forcing devices to use "IPv6+nat64" will help here?
> >>>> Eat own dogfood. Many IETF people are developers or work for
> companies having applications not working.
> >>>> As I said there were a minimum of applications that didn't work.
> Corporate VPNs largely did. Jen has the final numbers.
> >>> However, as long as even one application, such as one VPN, or one
> >>> literal IPv4 address, fails, that represents millions of failure cases
> >>> if we consider the whole world (e.g. imagine every hotel network in
> >>> the world running IPv6+NAT64 only). That simply isn't viable. Dual
> >>> stack in every hotel room in the world is viable, from the hotel
> guests'
> >>> point of view. Operators might not like it, but users wouldn't care.
> >>
> >> In hotel rooms and other "public" or "guest" networks, there are so many
> >> things that fail already, due to NAT, misconfigured firewalls,
> >> unmaintained blocklists, SSL-proxies and whatnot, so you can hardly
> >> expect any services other than basic web-surfing without https to work.
> >> Not that this is an ideal situation today, but i do not believe that "if
> >> even one VPN or one liter IPv4 address fails" should be a showstopper
> >> for introducing this.
> >
> > Hotels won't make that choice, but the providers of hotel networks will,
> > entirely based on their perception of the number of help desk calls
> > they will have to handle for any given change. Since they haven't even
> > made the move from IPv4 to dual stack, I think we'll wait a long time
> > before they attempt any form of IPv6-only. Sad but true.
> >
> >> Possibly, or even probably, introducing IPv6 (-only and NAT64) will even
> >> make the situation better for a lot of people, as you get rid of all the
> >> horrible NAT solutions for services that are already dual stacked.
> >
> > But those horrible NAT solutions are up and running today.
>
> It will be noticed that on NAT64 ESSID the experience is worse than on
> IPv4, at least for VPN sessions.
>


How would the vpn service be improved? If the VPN server / peer was ipv6
enabled then it would just be e2e v6, no?

I like to refer back to Occam’s Razor e2e v6 rather than transition Rube
Goldberg


> Alex
>
>   For this
> > class of operator, any change is bad news, unfortunately. What is their
> > incentive to make such a change?
> >
> >      Brian
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>