Tore,
I haven't tested, but I believe that if you were to hook up a standard Linux box to a ISP that provides /32 or shorter over MAP, you don't
Yes, indeed. In fact, almost all of the MAP CE implementations (that I am aware of) are open source/linux based - http://enog.jp/~masakazu/vyatta/map/ http://mapt.ivi2.org:8039/readme.txt Cheers, Rajiv -----Original Message----- From: Tore Anderson <tore@fud.no> Date: Monday, April 8, 2013 8:20 AM To: Mikael Abrahamsson <swmike@swm.pp.se>, nanog list <nanog@nanog.org> Cc: Rajiv Asati <rajiva@cisco.com> Subject: Re: Verizon DSL moving to CGN
* Tore Anderson
The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 component though, so there is some NAT involved in the overall solution, but it's pretty much the same as what we have in today's CPEs/HGWs. The only significant difference is that a MAP CPE must be prepared to not being able to use all the 65536 source ports.
BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE.
I find that the easiest way to visualise MAP is to take the 16 bits of TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4 address space, for a total of 48 "routable" bits. So while the primary use case for MAP is to provision less than 32 bits to the individual customers (say a "/34" -> 4 subscribers per IPv4 address w/16k ports each), you can also give out a "whole" /32 or a /24 or whatever - perhaps only to the customers that are willing to pay for the privilege.
I haven't tested, but I believe that if you were to hook up a standard Linux box to a ISP that provides /32 or shorter over MAP, you don't really need any special MAP support in the IP stack to make it go - you'd have to calculate the addresses to be used yourself, but once you've got them, you could just configure everything using standard "ip tunnel/address" commands.
It's quite neat, I think. :-)
Tore