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