The point is that the situation is that same for *all* the transition 
mechanisms, except DS-Lite, which was the first one.

Even lw4o6, which is a better choice than DS-LITE is not well supported even 
the CE is basically doing the same!

I've a recent presentation in the last APNIC meeting, which is also recorded in 
youtube:

https://conference.apnic.net/47/program/schedule/#/day/11/ipv4aas-tutorial-and-hands-on---part-1


Regards,
Jordi
@jordipalet
 
 

El 8/8/19 22:21, "NANOG en nombre de Lee Howard" <nanog-boun...@nanog.org en 
nombre de lee.how...@retevia.net> escribió:

    
    On 8/2/19 11:39 AM, Jay Hanke wrote:
    > Is there a summary presentation someplace laying out the options that
    > are active in the wild with some deployment stats?
    
    I can't think of a public presentation off the top of my head that 
    explains how each major transition technology works, and the pros and 
    cons of each. There must be one, but it's hard to cover the major 
    options in an hour.
    
    If you want to know who is using any given transition technology, 
    there's this crowd-sourced list:
    
    
https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0
    
    Very brief summary of options:
    
    NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, 
    too, or all your traffic will go through a translator (everything else 
    below assumes native IPv6 is deployed). State information can get 
    expensive. Well understood.
    
    Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel 
    (softwire) to a pre-configured DS-Lite box, which does NAT44. Works 
    fine, deployed at scale (see sheet above), but keeping state on lots of 
    NAT44 can get expensive at scale.
    
    NAT64. IPv6-only to users. DNS resolver given in provisioning 
    information is a DNS64 server. When it does a lookup but there's no 
    AAAA, it invents one based on the A record (e.g., 2001:db8:64::<IPv4 
    address>). The IPv6 prefix in the invented AAAA is actually a NAT64 
    translator. Pro: no CPE support required, well understood. Con: No 
    support for IPv4-only stuff in the prem, breaks DNSSEC.
    
    464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE 
    receives, it translates to IPv6 and forwards to a destination that's the 
    NAT64 server, which translates again. Pro: widely deployed at scale on 
    mobile networks. Con: Very little CPE support in home routers.
    
    MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
    provisioned with an IPv4 address and a range of ports. It does basic 
    NAT44, but only uses the reserved ports. Then it translates to IPv6 
    (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured 
    Border Relay (BR), which changes it to IPv4. Pro: Stateless, very 
    efficient. Con: Very little CPE support in home routers.
    
    Jordi is going to tell me there's plenty of support for 464xlat. 
    However, you can't go into any old electronics store in North America 
    and buy a home gateway with support for 464xlat or MAP. You can't buy 
    them directly from a vendor, unless you're large enough to request a 
    specific firmware build. Yes, you can get support from OpenWRT, but 
    that's probably not how you want your support team spending their time.
    
    CPE support is the next big frontier in IPv6 deployment.
    
    Lee
    
    >
    > On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG
    > <nanog@nanog.org> wrote:
    >> I understand that, but the inconvenient is the fix allocation of ports 
per client, and not all the clients use the same number of ports. Every option 
has good and bad things.
    >>
    >>
    >>
    >> MAP is less efficient in terms of maximizing the “use” of the existing 
IPv4 addresses.
    >>
    >>
    >>
    >> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
    >>
    >>
    >>
    >>
    >>
    >> Regards,
    >>
    >> Jordi
    >>
    >> @jordipalet
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" 
<nanog-boun...@nanog.org en nombre de baldur.nordd...@gmail.com> escribió:
    >>
    >>
    >>
    >> Hi Jordi
    >>
    >>
    >>
    >> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to 
avoid the expense and operative nightmare of having to run a redundant NAT 
server setup with thousands of users. MAP is the only alternative that avoids a 
provider run NAT server.
    >>
    >>
    >>
    >> Regards,
    >>
    >>
    >>
    >> Baldur
    >>
    >>
    >>
    >>
    >>
    >> On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG 
<nanog@nanog.org> wrote:
    >>
    >> Ask the vendor to support RFC8585.
    >>
    >>
    >>
    >> Also, you can do it with OpenWRT.
    >>
    >>
    >>
    >> I think 464XLAT is a better option and both of them are supported by 
OpenWRT.
    >>
    >>
    >>
    >> You can also use OpenSource (Jool) for the NAT64.
    >>
    >>
    >>
    >> Regards,
    >>
    >> Jordi
    >>
    >> @jordipalet
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" 
<nanog-boun...@nanog.org en nombre de baldur.nordd...@gmail.com> escribió:
    >>
    >>
    >>
    >> Hello
    >>
    >>
    >>
    >> Are there any known public deployments of MAP-E? What about CPE routers 
with support?
    >>
    >>
    >>
    >> The pricing on IPv4 is now at USD 20/address so I am thinking we are 
forced to go the CGN route going forward. Of all the options, MAP-E appears to 
be the most elegant. Just add/remove some more headers on a packet and route it 
as normal. No need to invest in anything as our core routers can already do 
that. No worries about scale.
    >>
    >>
    >>
    >> BUT - our current CPE has zero support. We are too small that they will 
make this feature just for us, so I need to convince them there is going to be 
a demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?
    >>
    >>
    >>
    >> What is holding MAP-E back?  In my view MAP-E could be the end game for 
IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The 
ISP networks are not forced to do a lot of processing such as CGN otherwise 
requires.
    >>
    >>
    >>
    >> I read some posts from Japan where users are reporting a deployment of 
MAP-E. Anyone know about that?
    >>
    >>
    >>
    >> Regards,
    >>
    >>
    >>
    >> Baldur
    >>
    >>
    >>
    >>
    >> **********************************************
    >> IPv4 is over
    >> Are you ready for the new Internet ?
    >> http://www.theipv6company.com
    >> The IPv6 Company
    >>
    >> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
    >>
    >>
    >> **********************************************
    >> IPv4 is over
    >> Are you ready for the new Internet ?
    >> http://www.theipv6company.com
    >> The IPv6 Company
    >>
    >> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
    >>
    >
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



Reply via email to