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
On Fri, 2 Aug 2019, Baldur Norddahl wrote:
be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any?
Broadcom supports MAP-E and LW4o6 encap/decap in fastpath on at least BCM63138 with their latest BSP versions. -- Mikael Abrahamsson email: swmike@swm.pp.se
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@nanog.org en nombre de baldur.norddahl@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.
On Fri, 2019-08-02 at 15:37 +0200, JORDI PALET MARTINEZ via NANOG 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.
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.
On Fri, 2 Aug 2019, Brian J. Murrell wrote:
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?
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, 2 Aug 2019 at 14:49, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
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?
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
On Fri, Aug 2, 2019 at 3:49 PM Brian J. Murrell <brian@interlinx.bc.ca> wrote:
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?
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
On 8/2/19 5:16 PM, Baldur Norddahl wrote:
Multiple customers share an IPv4 address each with an assigned port range.
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).
On Fri, Aug 2, 2019 at 5:33 PM Bryan Holloway <bryan@shout.net> wrote:
On 8/2/19 5:16 PM, Baldur Norddahl wrote:
Multiple customers share an IPv4 address each with an assigned port
range.
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).
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
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 of burying 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. Aled Morris via NANOG wrote:
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. JORDI PALET MARTINEZ via NANOG wrote:
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.
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 gets automatically 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
> 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 ********************************************** 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.
JORDI PALET MARTINEZ via NANOG wrote:
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
On Mon, 05 Aug 2019 06:42:30 +0900, Masataka Ohta said:
JORDI PALET MARTINEZ via NANOG wrote:
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.
So you're going to say what ports the users are forced to use...
Only users know what applications they are using.
When you don't know what applications on what ports they are using. Gotcha.
I'm not interested in poor IPv6.
Well... if you have poor IPv6 support from your ISP, we can understand that. Have you tried talking to your ISP and getting them to provide good IPv6 support?
Valdis Kletnieks wrote:
-> 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.
So you're going to say what ports the users are forced to use...
Like DHCP, yes. So?
Only users know what applications they are using.
When you don't know what applications on what ports they are using.
You don't have to know, because its user's problem.
I'm not interested in poor IPv6.
Well... if you have poor IPv6 support from your ISP, we can understand that.
You don't understand I was an active member of IPng WG trying to prevent the WG make poor decisions. I was only partially successful. Masataka Ohta
On Sat, Aug 3, 2019 at 11:30 AM JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> wrote:
> 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
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
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
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. -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Masataka Ohta Sent: Monday, 5 August 2019 11:07 AM To: nanog@nanog.org Subject: Re: MAP-E 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
This is not surprising to me as Dlink was one of my co-authors for RFC8585 ... and they indicated in v6ops that implementing CLAT was really easy. I guess they need to improve the GUI, etc. Note that with 464XLAT, you still need the NAT64 at the ISP side, and also, the traceroutes will shows something weird, so not trustable unless you understand very well how it works. However, testing a web site or other services will work fine. Regards, Jordi @jordipalet El 5/8/19 3:45, "NANOG en nombre de Philip Loenneker" <nanog-bounces@nanog.org en nombre de Philip.Loenneker@tasmanet.com.au> escribió: 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. -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Masataka Ohta Sent: Monday, 5 August 2019 11:07 AM To: nanog@nanog.org Subject: Re: MAP-E 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 ********************************************** 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.
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-bounces@nanog.org en nombre de baldur.norddahl@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.
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@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
Is there a summary presentation someplace laying out the options that are active in the wild with some deployment stats? 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-bounces@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
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_7NK... 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-bounces@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
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.
Actually your post is better than a presentation. I was quite surprised at the adoption rate of DS-Lite. There must be some pretty decent B4 implementations with that many operators deployed. Even though the spreadsheet is small sample size, there isn't much DS-lite deployment in the US. So from 10k feet, MAP-E is basically the same thing as DS-Lite except for the location of the NAT?
I think the only reason DS-Lite got more implementations is that it was the first and "only" choice or IPv6-only with IPv4aaS. Regards, Jordi @jordipalet El 8/8/19 22:57, "NANOG en nombre de Jay Hanke" <nanog-bounces@nanog.org en nombre de jayhanke@gmail.com> escribió: > 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. Actually your post is better than a presentation. I was quite surprised at the adoption rate of DS-Lite. There must be some pretty decent B4 implementations with that many operators deployed. Even though the spreadsheet is small sample size, there isn't much DS-lite deployment in the US. So from 10k feet, MAP-E is basically the same thing as DS-Lite except for the location of the NAT? ********************************************** 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.
On Thu, 8 Aug 2019, Jay Hanke wrote:
Actually your post is better than a presentation. I was quite surprised at the adoption rate of DS-Lite. There must be some pretty decent B4 implementations with that many operators deployed.
The DOCSIS residential gateway vendors seem to have converged on ds.lite, probably because it was the first one out the gate. I've seen support for this on RGs for other WAN technologies. It's not great, but it's what has the most support in devices available. Lots of ds.lite is in Germany, and most/all the cable operators there have converged on ds.lite. This is not uncommon that several operators in a country converge on a similar strategy. Engineers moving employment between operators bring with them the know-how and do the same thing over again at the new place, and also there is a kind of "herd immunity" against customer complaints if your deployment and service offering has similar properties to most of your competitors in the country. -- Mikael Abrahamsson email: swmike@swm.pp.se
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-a... Regards, Jordi @jordipalet El 8/8/19 22:21, "NANOG en nombre de Lee Howard" <nanog-bounces@nanog.org en nombre de lee.howard@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_7NK... 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-bounces@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
Lee Howard wrote:
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.
So, all we need is NAT44 CPE, which only uses a reserved block of ports, which is (semi) statically configured by ISP operated gateway. Pro: Stateless, very efficient, no IPv6 necessary Con: No current CPE support. As for protocol, assuming port mapping on UPnP gateway is statically configured by ISPs not changable from CPE side, GetListOfPortMappings() of UPnP should be useful for CPEs to know range of ports to be used by them. Masataka Ohta
On 8/8/19 9:00 PM, Masataka Ohta wrote:
As for protocol, assuming port mapping on UPnP gateway is statically configured by ISPs not changable from CPE side, GetListOfPortMappings() of UPnP should be useful for CPEs to know range of ports to be used by them.
There's actually a DHCPv6 option for specifying the port information in addition to the transition tech in use. I had previously inquired to NANOG about it, though I don't recall the specifics at this time. In theory, with that in place, a user could go buy any ol' RG style router with support for the proper transition tech and just plug and play like they currently do with native dual-stack networks. -- Brandon Martin
On 8/8/19 9:00 PM, Masataka Ohta wrote:
Lee Howard wrote:
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.
So, all we need is NAT44 CPE, which only uses a reserved block of ports, which is (semi) statically configured by ISP operated gateway.
How would you route from the provider edge? If CPE A has 192.0.2.15 port 1000-2999 and CPE B has 192.0.2.15 port 3000-4999, how does your BRAS or CMTS or edge router know whether to forward a packet to A or B? You could do policy routing or similarly do deep packet inspection, but you'd need a mechanism to provision that information into the provider edge router; you wouldn't manually configure match/set policy for each customer.
Pro: Stateless, very efficient, no IPv6 necessary Con: No current CPE support.
As for protocol, assuming port mapping on UPnP gateway is statically configured by ISPs not changable from CPE side, GetListOfPortMappings() of UPnP should be useful for CPEs to know range of ports to be used by them.
Do CPEs do this now, or is this another feature to ask vendors for? Lee
Masataka Ohta
Lee Howard wrote:
So, all we need is NAT44 CPE, which only uses a reserved block of ports, which is (semi) statically configured by ISP operated gateway.
How would you route from the provider edge?
If CPE A has 192.0.2.15 port 1000-2999
and CPE B has 192.0.2.15 port 3000-4999,
Oops,I concentrated on minimizing logging and forgot about that. Sorry. I assume COE gateway also act as NAT44, though no port translation necessary there.
how does your BRAS or CMTS or edge router know whether to forward a packet to A or B?
Incoming packets are forwarded to A or B by private IP address of A or B based on source port. Depending on configuration, some port may always accept incoming packets and other port accept incoming packets only when the port is used by an outgoing connection.
Pro: Stateless, very efficient, no IPv6 necessary Con: No current CPE support.
As for protocol, assuming port mapping on UPnP gateway is statically configured by ISPs not changable from CPE side, GetListOfPortMappings() of UPnP should be useful for CPEs to know range of ports to be used by them.
Do CPEs do this now, or is this another feature to ask vendors for?
I think there is no current CPE support. COE supporting GetListOfPortMappings() may not exist, either. Masataka Ohta
❦ 8 août 2019 16:18 -04, Lee Howard <lee.howard@retevia.net>:
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.
Is there a known deployment for a medium/large ISP? Thanks. -- Wrinkles should merely indicate where smiles have been. -- Mark Twain
On 8/9/19 1:32 AM, Vincent Bernat wrote:
❦ 8 août 2019 16:18 -04, Lee Howard <lee.howard@retevia.net>:
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. Is there a known deployment for a medium/large ISP?
Not a fixed/wireline ISP. The "con" that consumers' game consoles, smart TVs, and IoT things won't work is a pretty big "con." I was working with a small ISP that was running out of IPv4 addresses, and they kept saying "NAT64." I warned them that while NAT64 would solve their runout problem, it would drive a lot of unhappy customer calls. It would be interesting if someone offered a NAT64 service (maybe for a reduced price). Buyers could tell consumer electronics companies, "I can't use your device without IPv6." But qualifying the customer who would do that would be more expensive, I think, than just buying IPv4 addresses. Also but, would that be a Net Neutrality problem, charging less for a service that has arguably worse access to Amazon, Reddit, Twitter, etc.? Lee
Thanks.
Hi Lee,
Also but, would that be a Net Neutrality problem, charging less for a service that has arguably worse access to Amazon, Reddit, Twitter, etc.?
Net neutrality as it is here in Europe usually is satisfied when no preferential treatment is given to a limited set of services (Netflix has higher priority than Amazon Prime etc). The European regulators don't seem to specify things in technical terms but in "Apps" and "Services". As long as you don't treat those unfairly you should be fine. When you tell a regulator "yes, the new standard works better than the old standard, and we encourage everybody to support that new standard (which is a recognised best practice)" then there shouldn't be any problem. Cheers :) Sander
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... Following is my presentation at that time. https://conference.apnic.net/44/assets/files/APCS549/IPv6-support-at-NEC-CEs... 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@vx.jp.nec.com https://www.necplatforms.co.jp/en/ ========================
-----Original Message-----
From: NANOG <nanog-bounces@nanog.org> On Behalf Of Lee Howard
Sent: Friday, August 9, 2019 5:18 AM
To: nanog@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_7NK...
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<mailto: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-comparis
on/
Regards,
Jordi
@jordipalet
El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" <nanog-bounces@nanog.org en nombre de<mailto:nanog-bounces@nanog.org%20en%20nombre%20de%20baldur.norddahl@gmail.com>
baldur.norddahl@gmail.com<mailto:nanog-bounces@nanog.org%20en%20nombre%20de%20baldur.norddahl@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<mailto: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-bounces@nanog.org en nombre de<mailto:nanog-bounces@nanog.org%20en%20nombre%20de%20baldur.norddahl@gmail.com>
baldur.norddahl@gmail.com<mailto:nanog-bounces@nanog.org%20en%20nombre%20de%20baldur.norddahl@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 ?
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 ?
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.
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@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@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
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 El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" <nanog-bounces@nanog.org en nombre de baldur.norddahl@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@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@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
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@nanog.org <mailto:nanog-bounces@nanog.org> en nombre de baldur.norddahl@gmail.com <mailto:baldur.norddahl@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@consulintel.es <mailto:jordi.palet@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@nanog.org <mailto:nanog-bounces@nanog.org> en nombre de baldur.norddahl@gmail.com <mailto:baldur.norddahl@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 <mailto: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-bounces@nanog.org <mailto:nanog-bounces@nanog.org> en nombre de baldur.norddahl@gmail.com <mailto:baldur.norddahl@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.
Hi Lee, I recall the original sender of this post indicated a small number of users, that’s why I responded that. Regards, Jordi @jordipalet El 8/8/19 22:17, "NANOG en nombre de Lee Howard" <nanog-bounces@nanog.org en nombre de lee.howard@retevia.net> escribió: 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@nanog.org en nombre de baldur.norddahl@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@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@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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. ********************************************** 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.
On Fri, Aug 9, 2019 at 5:17 AM Lee Howard <lee.howard@retevia.net> wrote:
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
NAT64 / 464xlat / MAP all lend themselves well to regionalization / edge distribution. That’s how i roll 464xlat. Either with anycast of the well know prefix or dns64 or “dns view” base segmentation. Asking for a single box to do a 100g of nat state may be the wrong question. Worth noting, Yandex, a big shop, sponsored adding 464xlat CLAT to FreeBSD https://www.freebsd.org/releases/11.3R/relnotes.html#network-general
Regards,
Jordi
@jordipalet
El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" < nanog-bounces@nanog.org en nombre de baldur.norddahl@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@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@nanog.org en nombre de baldur.norddahl@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-bounces@nanog.org en nombre de baldur.norddahl@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.
On 2/Aug/19 14:17, Baldur Norddahl wrote:
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.
Actually, I think NAT64/DNS64/464XLAT is the best option, because as more IPv4 falls away, you are automatically translating less and going native IPv6 more. And there is nothing for you to "turn off" or migrate away from after all is said & done. Mark.
On 6 Aug 2019, at 9:05 am, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 2/Aug/19 14:17, Baldur Norddahl wrote:
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.
Actually, I think NAT64/DNS64/464XLAT is the best option, because as more IPv4 falls away, you are automatically translating less and going native IPv6 more. And there is nothing for you to "turn off" or migrate away from after all is said & done.
Mark.
Which only applies to DNS64 and not 464XLAT. That said, every IPv6 node should be attempting to connect over IPv6 first. That alone moves most of the traffic to IPv6 regardless of the IPv4aaS method in use. DNS64 also breaks DNSSEC which is not a good thing. DNS64 alone also depends on *everybody* having good (complete) IPv6 connectivity and not leaving IPv6 breakages uncorrected. There is no fallback to IPv4 with DNS64 alone. If you also have 464XLAT with DNS64 then there is NO DIFFERENCE to MAP-[ET] or DS-Lite in terms of traffic shifting to native IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
The difference is that 464XLAT/NAT64 is the only one that runs in cellular networks. Also with 464XLAT, you don't need DNS64. This document is already in the RFC Editor Queue: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ El 6/8/19 1:24, "NANOG en nombre de Mark Andrews" <nanog-bounces@nanog.org en nombre de marka@isc.org> escribió: > On 6 Aug 2019, at 9:05 am, Mark Tinka <mark.tinka@seacom.mu> wrote: > > > > On 2/Aug/19 14:17, Baldur Norddahl wrote: > >> >> >> 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. > > Actually, I think NAT64/DNS64/464XLAT is the best option, because as > more IPv4 falls away, you are automatically translating less and going > native IPv6 more. And there is nothing for you to "turn off" or migrate > away from after all is said & done. > > Mark. Which only applies to DNS64 and not 464XLAT. That said, every IPv6 node should be attempting to connect over IPv6 first. That alone moves most of the traffic to IPv6 regardless of the IPv4aaS method in use. DNS64 also breaks DNSSEC which is not a good thing. DNS64 alone also depends on *everybody* having good (complete) IPv6 connectivity and not leaving IPv6 breakages uncorrected. There is no fallback to IPv4 with DNS64 alone. If you also have 464XLAT with DNS64 then there is NO DIFFERENCE to MAP-[ET] or DS-Lite in terms of traffic shifting to native IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ********************************************** 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.
participants (18)
-
Aled Morris -
Baldur Norddahl -
Brandon Martin -
Brian J. Murrell -
Bryan Holloway -
Ca By -
Jay Hanke -
JORDI PALET MARTINEZ -
Lee Howard -
Mark Andrews -
Mark Tinka -
Masanobu Kawashima -
Masataka Ohta -
Mikael Abrahamsson -
Philip Loenneker -
Sander Steffann -
Valdis Klētnieks -
Vincent Bernat