[162280] in North American Network Operators' Group
Re: Verizon DSL moving to CGN
daemon@ATHENA.MIT.EDU (Tore Anderson)
Mon Apr 8 08:21:03 2013
Date: Mon, 08 Apr 2013 14:20:51 +0200
From: Tore Anderson <tore@fud.no>
To: Mikael Abrahamsson <swmike@swm.pp.se>, nanog list <nanog@nanog.org>
In-Reply-To: <51629C0B.30801@fud.no>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
* 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
