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 <b...@herrin.us> wrote: > On Tue, Sep 18, 2012 at 11:39 AM, <valdis.kletni...@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 <o...@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 ................ her...@dirtside.com b...@herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004