Verizon DSL moving to CGN

Mon Apr 8 12:20:51 UTC 2013

* 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