IPv6 Ignorance

Wed Sep 19 05:27:29 UTC 2012

6rd itself isn't inherently silly.

Mapping your customers onto an entire /32 is.

You're much better off taking the size of your largest prefix and
assigning a number of bis for the number of prefixes you have.
For example, if you have /14, /14, /15, /16, /16, /16, /18, /19, /20, /22,
/22, /22, /22, /23 and need to deploy 6rd, you could easily fit that
into a 48-18=30 (round up to 28) - 4 (14 prefixes) = /24.

Let's say your /24 is 2001:db00::/24.
Your /14s would map to 2001:db00::/28 and 2001:db10::/28.
Your 15 would map to 2001:db20::/28
Your 16s would map to 2001:db30::/28, 2001:db40::/28, 2001:db50::/28.
The 18, 19, and 20 would get 2001:db60:::/28 - 2001:db80::/28.
The 22s would get 2001:db90::/28 - 2001:dbc0::/28.
The /23 would get 2001:dbd0::/28 and you'd still have 2001:dbe0
through 2001:dbff available. (2 extra /28s).

Note, that's with the assumption of mapping 6rd onto /48s.

If you want to map 32 bits, then, you need to degrade your customers
6rd experience and give them smaller blocks until you can give them
real IPv6 service.

I do not support address policy to make poor planning easier.

Owen

On Sep 18, 2012, at 15:18 , William Herrin <bill at herrin.us> wrote:

> On Tue, Sep 18, 2012 at 11:39 AM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said:
>> 
>>> Then we need 32 bits to overlay the customer's IPv4 address for
>>> convenience within our 6RD network.
>> 
>> Well yeah.  You blow 32 bits for silly reasons, you run out of bits. Film at 11.
> 
> Silly reason? Hardly! 6RD lets you deploy IPv6 immediately to all
> customers. It's a stateless tunnel. Direct the packets into an
> encapsulator and any customer who wants them need only catch them on
> their IPv4 address. Without you having to change out anything else in
> your network. Hitch is: if you have a whole lot of discontiguous IPv4
> prefixes, sorting which maps to where in a compact IPv6 prefix is
> challenging. Much easier to just map the entire IPv4 space and be done
> with it.
> 
> Poor plan. But much easier.
> 
> 
> On Tue, Sep 18, 2012 at 10:01 AM, Owen DeLong <owen at delong.com> wrote:
>>> Then we need 32 bits to overlay the customer's IPv4 address for
>>> convenience within our 6RD network. So that leaves us 16 bits. But we
>>> don't want the native network to overlay the 6RD network because we
>>> want a real simple /16 route into the nearest 6rd encapsulator. And we
>>> don't want to advertise multiple BGP prefixes either. So we claim
>>> another bit and allocate our native infrastructure from the /16 that
>>> doesn't overlap the 6rd setup.
>> 
>> No, you really don't. This absurdity (and the ridiculous design of 6RD)
>> are so problematic in this area that I cannot begin  to describe what a
>> terrible idea it is.
> 
> In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html
> I complained about mapping the full 32-bits of IPv4 address into an
> IPv6 prefix. You responded, "You say that like it's somehow a bad
> thing," and "I'm simply not seeing a problem."
> 
> Have you come around to my way of thinking that using 6RD with a full
> 32-bit IPv4 mapping is not such a hot idea?
> 
> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004