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