MAP-E

Thu Aug 8 20:15:01 UTC 2019

On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote:
>
> The cost of sharing IPs in a static way, is that services such as Sony 
> Playstation Network will put those addresses in the black list, so you 
> need to buy more addresses. This hasn’t been the case for 
> 464XLAT/NAT64, which shares the addresses dynamically.
>
> Furthermore, if some users need less ports than others, you 
> “infra-utilize” those addresses, which again is not the case for 
> 464XLAT/NAT64. Each user gets automatically as many ports as he needs 
> at every moment.
>
> So, you save money in terms of addresses, that you can invest in a 
> couple of servers running a redundant NAT64 setup 
> (https://www.jool.mx/en/session-synchronization.html). Those servers 
> can be actually VMs, so you don’t need dedicated hardware, especially 
> because when you deploy IPv6 with 464XLAT, typically 75% (and going 
> up) of you traffic will be IPv6 and only 25% will go thru the NAT64.
>
You work on much smaller networks than I do if a "couple of servers 
running Jool" can handle your load.  Jool is great, and the team that 
built it is great, but a couple of 10Gbps NICs on a pizza box doesn't go 
very far. I've tried 100Gbps and can't get the throughput with any 
normal CPU. Hoping to get back to it and run some actual measurements.

Lee

> Regards,
>
> Jordi
>
> @jordipalet
>
> El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" 
> <nanog-bounces at nanog.org <mailto:nanog-bounces at nanog.org> en nombre de 
> baldur.norddahl at gmail.com <mailto:baldur.norddahl at gmail.com>> escribió:
>
> The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 
> users sharing one IPv4), leaving 12 bits for customer ports (4096 
> ports) and a current price of USD 20 per IPv4 address, this gives a 
> cost of USD 1.25 per user for a fully redundant solution. For us it is 
> even cheaper as we can recirculate existing address space.
>
> Regards,
>
> Baldur
>
> On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ 
> <jordi.palet at consulintel.es <mailto:jordi.palet at consulintel.es>> 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-bounces at nanog.org <mailto:nanog-bounces at nanog.org> en
>     nombre de baldur.norddahl at gmail.com
>     <mailto:baldur.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 <mailto:nanog-bounces at nanog.org> en
>         nombre de baldur.norddahl at gmail.com
>         <mailto:baldur.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.
>
>
> **********************************************
> 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/20190808/03e22549/attachment.html>