MAP-E

Fri Aug 9 06:40:17 UTC 2019

Hi all,

> CPE support is the next big frontier in IPv6 deployment.

That’s why we discussed about the issue with Jordi and other vendors on APNIC 44
almost 2 years ago.
https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-with-ipv6-ce-vendors

Following is my presentation at that time.
https://conference.apnic.net/44/assets/files/APCS549/IPv6-support-at-NEC-CEs.pdf

After that, we standardized RFC8585.
So, next step is implemeting transition technologies and deployment.

Please let me know if there’s opportunity to use transition technologies
we have minimum order quantity though, we may discuss about it.

Let’s cross the chasm together. :-)

Regards,
Masanobu

========================
 NEC Platforms, Ltd.
 KAWASHIMA Masanobu
 kawashimam at vx.jp.nec.com
 https://www.necplatforms.co.jp/en/
========================

> -----Original Message-----

> From: NANOG <nanog-bounces at nanog.org> On Behalf Of Lee Howard

> Sent: Friday, August 9, 2019 5:18 AM

> To: nanog at nanog.org

> Subject: Re: MAP-E

>

>

> 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 at nanog.org<mailto:nanog at 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-comparis

> >> on/

> >>

> >>

> >>

> >>

> >>

> >> Regards,

> >>

> >> Jordi

> >>

> >> @jordipalet

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" <nanog-bounces at nanog.org en nombre de<mailto:nanog-bounces at nanog.org%20en%20nombre%20de%20baldur.norddahl at gmail.com>

> baldur.norddahl at gmail.com<mailto:nanog-bounces at nanog.org%20en%20nombre%20de%20baldur.norddahl at 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 at nanog.org<mailto:nanog at 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-bounces at nanog.org en nombre de<mailto:nanog-bounces at nanog.org%20en%20nombre%20de%20baldur.norddahl at gmail.com>

> baldur.norddahl at gmail.com<mailto:nanog-bounces at nanog.org%20en%20nombre%20de%20baldur.norddahl at 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.

> >>

> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190809/ed416552/attachment.html>