AT&T UVERSE Native IPv6, a HOWTO
Jean-Francois.TremblayING at videotron.com
Jean-Francois.TremblayING at videotron.com
Fri Nov 29 13:47:38 UTC 2013
> De : Mikael Abrahamsson <swmike at swm.pp.se>
> A : Mark Andrews <marka at isc.org>,
> >>> You can hand out /48 as easily with 6rd as you can natively.
>
> "As easily". It's easier to either hand out /64 by means of 1:1 mapping
> IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than
> to get into the whole backend mess of having multiple 6RD domains with
> multiple configs per IPv4 subnet etc.
>
> I agree with you theoretically, but in practice I disagree.
Some hard data points here, coming from one of the rare operator
who actually deployed 6RD sub-domains to all its customers (to my
knowledge).
In practice, most 6RD implementations that support option 212 do
support IPv4MaskLen properly these days. It wasn't the case 3 years ago,
but we worked a lot with vendors to make it right. Seems ok now,
we mostly have a 6RD population of D-Link and Cisco/Linksys.
On the backend side, it's really not that bad. A one-page TCL
handles around 15-16 sub-domains for us without noticeable impact
on the DHCP servers CPU. Configuring the relays with all the
tunnels can be a bit of fun playing with hex maths, but it's
not too bad either.
So I agree with Mark, it's not that complex. I can't agree with
him on the prefix size though. We hand out /60s because we feel
it's enough from a transition point of view (these are short-lived
anyway) and offering a bigger size would really use too much space.
Offering /48s out of a single /16 block, to take a simple example,
would use a whole /32. This space wouldn't be used much anyway,
given that most 6RD routers use only one /64, sometimes two.
I argue that a /60 is actually the best compromise here, from
a space and usage point of view.
/JF
Videotron, AS5769
More information about the NANOG
mailing list