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