MAP-E

Mailman List Mirror (Read Only)
1

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

2

Broadcom supports MAP-E and LW4o6 encap/decap in fastpath on at least BCM63138 with their latest BSP versions.

3

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

4

Will any of these (including MAP-E) support such nasty (in terms of
burying IP addresses in data payloads) protocols as FTP and SIP/SDP?

Cheers,
b.

5

LW4o6 is regular NAT44 and then tunnel encap. MAP-E is similar.

So if there is NAT44 helper for these protocols then it should work the same as if you just had NAT44.

6

I’m a fan of these solutions that (only) use NAT44 in the CPE as this is exactly what they’re currently doing, and the CPE vendors have already “solved” the problem of application support (SIP, FTP etc.) at least as far as the end-user is concerned.

It seems that introducing an extra layer of NAT at the ISP for NAT444 is creating a range of new problems, not least being scalability. Big CGNAT boxes are expensive.

Aled

7

All MAP-E does is reserving a port range for each customer. So customer A might be assigned port range 2000-2999, customer B gets 3000-3999 etc. The traffic is then routed to the correct customer using port range in addition to the destination IP address. This is done by encapsulating the original IPv4 packet in an IPv6 tunnel packet.

Multiple customers share an IPv4 address each with an assigned port range.

The customer CPE router does what it has always done. It does the NAT function but is restricted to only use the port numbers assigned. Therefore anything that works today will continue to work, providing it does not require access to hard coded port numbers. So customer A can not run a web server on port 80. But he could run a web server on port 2080 if he wanted to. Of course few customers are going to run inbound services with this setup.

NAT helpers on the CPE for FTP and SIP should work as expected.

I like the approach because no actual NAT is going on in the ISP network. It is almost the same as dual stack except a few bits of the port number is used for routing purposes. You need a device to do the MAP encapsulation but everything else in your network only has to do ordinary IPv6. Many core routers have MAP support now, so you might not even need a dedicated MAP encapsulation device.

Regards,

Baldur

8

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

9

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

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

10

One downside that has been brought up on the list before is that a DDoS attack against a single subscriber will impact many, but that particular drawback may not outweigh the benefits (costs).

11

Is there a summary presentation someplace laying out the options that
are active in the wild with some deployment stats?

12

That is true for every CGN solution. At least with MAP the DDoS will only hit multiple users if the attackers hit random port numbers.

Regards,

Baldur

13

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

14

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.

Regards,

Jordi

@jordipalet

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

15

Brian J. Murrell wrote:

You can also use OpenSource (Jool) for the NAT64.

Will any of these (including MAP-E) support such nasty (in terms ofburying IP addresses in data payloads) protocols as FTP and SIP/SDP?

Are you saying ICMP and DNS nasty?

As DNS protocol is still actively maintained, keeping NAT gateways
transparent to DNS is not easy.

I'm a fan of these solutions that (only) use NAT44 in the CPE as this
is exactly what they're currently doing, and the CPE vendors have
already "solved" the problem of application support (SIP, FTP etc.)
at least as far as the end-user is concerned.

It's better to modify NAT to preserve the end to end transparency.
See draft-ohta-e2e-nat-00 for details.

The cost of sharing IPs in a static way, is that services such asSonyPlaystation Network will put those addresses in the black list,so you need to buy more addresses. This hasn’t been the case for464XLAT/NAT64, which shares the addresses dynamically.

A problem of dynamic sharing is that logging information to be
used for such purposes as crime investigation becomes huge.

Furthermore, if some users need less ports than others, you"infra-utilize" those addresses,

Users needing more ports should pay more money and share an
IP address with smaller number of users.

which again is not the case for 464XLAT/NAT64. Each user getsautomatically as many ports as he needs at every moment.

Unless all the ports are used up.

Thus, even with dynamic port assignment, users needing more
ports should pay more money and share an IP address with
smaller number of users.

          Masataka Ohta

16

The cost of sharing IPs in a static way, is that services such as

    > SonyPlaystation 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.
    
    A problem of dynamic sharing is that logging information to be
    used for such purposes as crime investigation becomes huge.

-> Of course, everything has good and bad things, but with NAT444 you need to do the same, and because if you deploy 464XLAT you have less than 25% (and going down) of your traffic with IPv4, your cost for logging decreases. I'm assuming that you follow for IPv6 RIPE690 recommendations and you do persistent prefixes to customers, otherwise you also need IPv6 logging (but this is not different regardless of what transition mechanism you use).

    > Furthermore, if some users need less ports than others, you
    > "infra-utilize" those addresses,
    
    Users needing more ports should pay more money and share an
    IP address with smaller number of users.

-> I don't agree. Users don't know if they need more or less ports, and this is something that may happen dynamically, depending on what apps are you using in your home, or if it is Xmas and you have extra family at home. This is not good for users, is not good for ISPs. If ISPs want to provide "different" services they should CLEARLY say it: "Dear customer, you have two choices 4.000 ports, 16.000 ports or all the ports for you with a single IP address". Otherwise you're cheating to customers, which in many countries is illegal, because providing a reduced number of ports IS NOT (technically) Internet connectivity, is a reduced functionality of Internet connectivity, and you must (legally) advertise it and of course, most customers don't understand that!
    
    > which again is not the case for 464XLAT/NAT64. Each user gets
    > automatically as many ports as he needs at every moment.
    
    Unless all the ports are used up.

-> That's right, but you need to calculate a sufficient number of IPv4 addresses for your pool (which for sure will be lower than in MAP or lw4o6 or DS-Lite), and even if your number of customers go up, because more and more services are available with IPv6, your number of IPv4 will not keep growing. If you define 4.000 ports per customer, some customers may be using only 300 ports (average) and that means that you're infra-utilizing 3,700 ports x number of users with that average. Not good!
    
    Thus, even with dynamic port assignment, users needing more
    ports should pay more money and share an IP address with
    smaller number of users.

-> Never we should have charged users for IP addresses. This is a bad business model. Is not technically a good thing to provide non-persistent addresses. If we keep saying that, we will end up providing a single IPv6 address to every customer and doing NAT again. If an ISP want to do that, fine, but the competitors will be smarter (hopefully!).
    
              Masataka Ohta

17

A problem of dynamic sharing is that logging information to be used
for such purposes as crime investigation becomes huge.

-> Of course, everything has good and bad things, but with NAT444 you
need to do the same,

With static port range assignment, we don't have to.

I'm assuming that you follow for IPv6 RIPE690
recommendations and you do persistent prefixes to customers,

I'm not interested in poor IPv6.

Users needing more ports should pay more money and share an IP
address with smaller number of users.

-> I don't agree. Users don't know if they need more or less ports,
and this is something that may happen dynamically, depending on what
apps are you using in your home, or if it is Xmas and you have extra
family at home.

Only users know what applications they are using.

If
ISPs want to provide "different" services they should CLEARLY say it:
"Dear customer, you have two choices 4.000 ports, 16.000 ports or all
the ports for you with a single IP address".

That's what I have been saying.

Otherwise you're
cheating to customers, which in many countries is illegal, because
providing a reduced number of ports IS NOT (technically) Internet
connectivity, is a reduced functionality of Internet connectivity,

As Baldur Norddahl wrote:

All MAP-E does is reserving a port range for each customer. So
customer A might be assigned port range 2000-2999, customer B gets
3000-3999 etc.

we are talking about providing users a reduced number of ports
from 64K to, say, 2K.

As such, I'm afraid you have a very strange idea on Internet
connectivity, which is not shared by rest of us.

and you must (legally) advertise it and of course, most customers
don't understand that!

Most customers should choose least expensive option without
understanding anything, of course.

If you define 4.000 ports per
customer, some customers may be using only 300 ports (average) and
that means that you're infra-utilizing 3,700 ports x number of users
with that average. Not good!

Are you saying allocating a customer /48 IPv6 address is not good
because there is only 5 /64 links (average) used, which
infra-utilizing 64K /64?

-> Never we should have charged users for IP addresses. This is a bad
business model.

Feel free to ignore reality of ISP business.

              Masataka Ohta

18

I view it as an operative benefit of MAP that it is very stable in regards what happens if the ports are used up. This will never affect other users, as it could with old fashioned CGN. And in fact, there is almost nothing that could affect MAP but plenty of things that could go wrong with your CGN.

In the case a user has a problem with too few available ports he will contact our support. They will either advise him on what he can do to use less ports (example, tell the user to do less bittorrent). Or they will tell the user about the option of using IPv6 for his purpose or that he could pay for a dedicated non shared IPv4 address. But they would never need to escalate to have anything done to the non-existent CGN. Some might not like it, but this is very sound from a business perspective.

Even the case of a DDoS attack. For my scheme with 16 users sharing an IPv4, the attack could affect all 16 users. For CGN it is usually many more. Or the case of Playstation network. Yes they WILL blacklist your CGN just the same as they can blacklist a shared MAP ip address. Except it affects more users. There is some advantage in having less dense usage of the address space. As a site site probably has less than 1 out of 16 chance of blacklisting someone, our support staff can solve a problem for a customer by simply moving him to a different shared IPv4 - they could not do that for a CGN solution, or if they could, the alternative would also be blacklisted.

Regards,

Baldur

19

Baldur Norddahl wrote:

Or the case of Playstation network. Yes they WILL blacklist your CGN
just the same as they can blacklist a shared MAP ip address. Except it
affects more users.

If IP address sharing by blocks of ports becomes common and there is
typical block size (say, 1024), blacklisting will be done block-wise.

              Masataka Ohta

20

Moving away from the discussion around what technology people may choose to go with, and instead what CPEs may be suitable...

I know this is 464XLAT rather than MAP-E that was originally requested, but recent versions of D-Link firmware, eg for the DVA-2800, include the CLAT functionality. My testing in November last year showed that it only partially worked, with the traceroutes to 64:ff9b::1.1.1.1 working, but it would not automatically translate a traceroute to 1.1.1.1 to the IPv6 version. There have been a few new revisions since then and it is on my to-do list to re-test things, but I haven't had the time.

It is also worth noting that, in the original firmware revision I tested, I had to manually enter the URL for the CLAT configuration screen. It simply wasn't on the menu. On another version, it had a link to DS-Lite configuration, and from there you get a link to the CLAT options. It is possible that other devices and/or vendors also have this option, or options for similar technologies such as MAP-E, but they just don't have a link to it in the interface.