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

["Rajiv Asati (rajiva)" <rajiva () cisco com>]

Adrian,

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.


Cheers,
Rajiv

-----Original Message-----
From: "nanog-request () nanog org" <nanog-request () nanog org>
Reply-To: "nanog () nanog org" <nanog () nanog org>
Date: Tuesday, September 25, 2012 12:08 AM
To: "nanog () nanog org" <nanog () nanog org>
Subject: NANOG Digest, Vol 56, Issue 84

> Date: Mon, 24 Sep 2012 22:42:46 +0100
> From: Mike Jones <mike () mikejones in>
> To: Adrian Bool <aid () logic org uk>
> Cc: "nanog () nanog org" <nanog () nanog org>
> Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
> Message-ID:
>       <CAAAas8H8ERETrcnn0TaFD3cNToAfpdy12G6goNP5e=2cYtH1bQ () mail gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> On 24 September 2012 21:11, Adrian Bool <aid () logic org uk> wrote:
> > On 24 Sep 2012, at 17:57, Tore Anderson
> > <tore.anderson () redpill-linpro com> wrote:
> >
> > > * Tore Anderson
> > >
> > > > I would pay very close attention to MAP/4RD.
> > >
> > > FYI, Mark Townsley had a great presentation about MAP at RIPE65 today,
> > > it's 35 minutes you won't regret spending:
> > >
> > > https://ripe65.ripe.net/archives/video/5
> > > https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24
> > > -2012.pdf
> >
> > Interesting video; thanks for posting the link.
> >
> > This does seem a strange proposal though.  My understanding from the
> > video is that it is a technology to help not with the deployment of IPv6
> > but with the scarcity of IPv4 addresses.  In summary; it simply allows a
> > number of users (e.g. 1024) to share a single public IPv4 address.
> >
> > My feeling is therefore, why are the IPv4 packets to/from the end user
> > being either encapsulated or translated into IPv6 - why do they not
> > simply remain as IPv4 packets?
> >
> > If the data is kept as IPv4, this seems to come down to just two changes,
> >
> > * 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.
> > * A CE router being instructed to constrain itself to using a limited
> > set of ports on the WAN side in its NAT44 implementation.
> >
> > Why all the IPv6 shenanigans complicating matters?
>
> While you could do something similar without the encapsulation this
> would require that every router on your network support routing on
> port numbers, by using IPv6 packets it can be routed around your
> network by existing routers. And it's not like anyone is going to be
> deploying such a system without also deploying IPv6, so it's not
> adding any additional requirements doing it that way.
>
> - Mike
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 24 Sep 2012 23:34:30 +0100
> From: Adrian Bool <aid () logic org uk>
> To: "nanog () nanog org" <nanog () nanog org>
> Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
> Message-ID: <8BEEBCDA-B6FA-4407-BF95-E122B26F4916 () logic org uk>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 24 Sep 2012, at 22:42, Mike Jones <mike () mikejones in> wrote:
>
> > While you could do something similar without the encapsulation this
> > would require that every router on your network support routing on
> > port numbers,
>
> Well, not really.  As the video pointed out, the system was designed to
> leverage hierarchy to reduce routing complexity.   Using the hierarchy,
> port number routing is only required at the level where a routes diverge
> on a port basis - which if you're being sensible about such a deployment
> would only be at the edge of the access layer.
>
> aid