AT&T UVERSE Native IPv6, a HOWTO

Nick Cameo symack at gmail.com
Fri Nov 29 13:54:48 UTC 2013


They are all the same, ATT, Bell Canada, Cogeco......

On 11/29/13, Jean-Francois.TremblayING at videotron.com
<Jean-Francois.TremblayING at videotron.com> wrote:
>> 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