Throw me a IPv6 bone (sort of was IPv6 ignorance)


MAP facilitates both IPv6 deployment and IPv4 address exhaustion without
involving any CGN mess in the network. This allows the home networks to
stay dual-stack, use IPv6 as possible, and resort to IPv4 if IPv6 is not
feasible for the intended destinations.

One could promote the intent being that as more and more traffic goes over
IPv6, less and less IPv4 will be needed (thereby shrinking the reliance on
IPv4 ports sharing).

Note that MAP Translation mode (i.e. MAP-T) does not involve any
encapsulation, so, any QoS or Security or LI or DPI or Caching needing
access to Layer4 info (i.e. UDP/TCP ports) would work just fine anywhere
in the network. In case of MAP-E (Encapsulation mode), layer4 info (i.e.
UDP/TCP ports) is not available in the network (until at boundary of the
network where decapsulation is done).

* The ISP's router to which the user connects being
able to route packets on routes that go beyond the
IP address and into the port number field of TCP/UDP.

Nope. The routers still follow the dynamic IPv4 and IPv6 routing for
packet forwarding. That is UNCHANGED.

The routers (expected to the boundary routers/ASBR, not the PE routers
connecting the users) must have to look at the ports for IPv4->IPv6
stateless translation. Once translated, routing lookup as usual.

* A CE router being instructed to constrain itself to
using a limited set of ports on the WAN side in its
NAT44 implementation.

Indeed. And it is not much different from how it works today. Almost all
CPEs (I.e. Residential routers) work with limited set of ports (typically
2000) for dynamic NAT44 anyway. Of course, when MAP is enabled, the range
would no longer be the default (as is the case today), rather something
that is assigned using DHCP or TR069. That's in the control plane.