RE: IPv6 only host NAT64 requirements?

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ole Troan [mailto:[e-mail]]
> Envoyé : lundi 20 novembre 2017 11:38
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Jen Linkova; 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> Med,
> 
> >>>
> >>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
> >> appropriate "IPv4 service continuity" solution here.
> >>
> >> Why not?
> >
> > [Med] Because dual-stack can do the job without any extra effort.
> 
> That's not a valid answer, when the question to be explored is "Is it
> possible to run IPv6 only hosts?".

[Med] You should admit that there are questions that don't make sense if not contextualized.  

> 
> The arguments against dual stack:
>  - expensive to operate
>  - little progress towards the end goal of IPv6 only

[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? 

> 
> I think you can make a fair case that the end-user experience today is
> best with IPv4 only.

[Med] It depends for "which user", Ole. Consider the example of a bittorrent user who may prefer IPv6 vs. IPv4.

> 
> >> Interesting to hear your views here, especially since it "almost"
> worked
> >> at IETF100.
> >
> > [Med] I don't have any doubt that NAT64 will work module some issues and
> fixes (more can be found in https://tools.ietf.org/html/rfc6889#section-3
> (Analysis of Stateful 64 Translation)). There are deployments cases where
> these fixes are wroth to be enforced, while it is not justified in others.
> I'm for NAT64 as an "IPv4 service continuity" for mobile networks where
> there is a pressure on private IPv4 addresses, but I'm for DS-Lite and
> MAP-E for fixed networks given there is no implications on the host
> itself; the "complexity" will be hidden by a CPE.
> >
> > It is a case by case exercise.
> 
> Again, trying to move us forward with IPv6 only hosts.
> 
> >>> I need:
> >>>> - No dependency on DNS64. Want to use recursive resolver I trust plus
> >>>> local validating resolver.
> >>>> - Not depend on the success of PCP for NAT64 prefix discovery
> >>>> - If the host couldn't learn the NAT64 prefix any other way, I
> suppose
> >> it
> >>>> could throw an ICMP echo towards
> >>>>  64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
> >>>>
> >>>
> >>> [Med] Fair. That is another "add my favorite solution" to the list.
> >>>
> >>>> But I also see there being different deployment options here.
> >>>> Btw, for multiple NSPs, couldn't you partly solve that by injecting
> >> more
> >>>> specifics into routing?
> >>>
> >>> [Med] It is not only about forwarding/routing, but also how a host can
> >> pick the appropriate prefix64 for address synthesis. Things may be
> obvious
> >> if you can consider the example of RFC7050:
> >>>
> >>>
> >>>                     NAT64 "A" ----- IPv4-only servers in a data center
> >>>                    /
> >>>  IPv6-only node---<
> >>>                    \
> >>>                     NAT64 "B" ----- IPv4 Internet
> >>
> >> Firstly this seems like it is over engineered. Has anyone actually
> >> deployed NAT64 this way?
> >
> > [Med] This is a scenario that can be considered by some mobile operators
> at the Gi interface. Multiple prefixes are discussed in Section 4.2. of
> RFC7269 (NAT64 Deployment Options and Experience) that was produced by
> v6ops.
> 
> You can achieve load-balancing without having to push that requirement all
> the way down to the host.

[Med] I know. There is no reco to achieve NAT64 load-balancing. It is legitimate to hear from both of them. 

> 
> >> (Given that this is quite rare even in IPv6 only or IPv4 only
> scenarios.
> >> Look at implementation status of RIO for example).
> >>
> >> Secondly, RFC7050 says:
> >>
> >>   The heuristic discovery method described herein does not support
> >>   learning of the possible rules used by a DNS64 server for mapping
> >>   specific IPv4 address ranges to separate Pref64::/n prefixes.
> >>   Therefore, nodes will use the same discovered Pref64::/n to
> >>   synthesize IPv6 addresses from any IPv4 address.  This can cause
> >>   issues for routing and connectivity establishment procedures.  The
> >>   operator of the NAT64 and the DNS64 ought to take this into account
> >>   in the network design.
> >>
> >> Which to me reads, this just doesn't work.
> >
> > [Med] Correct. This is one of the limitations of the heuristic approach.
> >
> >>
> >> If we think NAT64 is a fundamental piece of technology to make progress
> on
> >> the transition, then I think we should focus on making it as simple and
> >> deployable as possible.
> >
> > [Med] NAT64 spec does not make any assumption about the deployment case.
> Its limitations are well-known and documented since years.
> >
> > IMHO, the required pieces for "simple" deployment scenarios are out
> there:
> > - prefix discovery using the heuristic
> > - local address synthesis to solve issues related to address
> literals/referrals.
> >
> > Advanced features have been also specified, e.g.,
> > - if you want to allow for incoming connections: e.g., access a video
> server
> > - if you want to avoid overloading NAT64 with all sorts of ALGs
> > - if you want to avoid draining the battery of your mobile because of
> the keepalive messages
> 
> Yep, but I think the cat is largely out of the bag here, and an
> application must work in the "smallest common denominator" network.

[Med] More concretely? 

> 
> Cheers,
> Ole