* 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