On Dec 21, 2005, at 1:34 PM, Jeroen Massar wrote:
Thanks. I also just want to add that I'm not expecting to be able to do every single thing with IPv6 that we could with IPv4, it's a different protocol on more levels than just addressing. However, the original question was about what experiences people had with IPv6, and I think it's an appropriate point. The more deviation between how we have to do business in IPv6 and how we're doing it now in IPv4 adds dramatically to the pain of transitioning. The disincentives for a small-mid sized network to moving to IPv6 are pretty big right now, which means very few of us are going to do it willingly. (Remember, the little guys are who are going to be buying IPv6 transit from the big guys, so it's in everyone's best interest to ease adoption)
Yes, but the routing for these networks are different. If AS numbers were infinite I'd run each one with a different ASN. The paths, policies and providers to each network are different, so I believe they deserve different routing. In IPv4 land, the line between IP allocation and IP routing was pretty clear. The RIR didn't care how you announced it, you just had to ensure that the rest of the world heard it. A pretty fair nearly-world-wide compromise was that you could break your network up into as many pieces as you wanted, just don't expect anything smaller than a /24 to be heard. I think this is a pretty fair balance. For us with a /20, we could break our network up into 16 pieces if we really had to, but for us we were content with 4 pieces. In IPv6 land, the RIRs are dictating routing policy as well as allocation policy. With the current /44 proposal (with acknowledgment that Kevin Loch says things might be changing), which would be enough for all but the largest enterprise customers, I still wouldn't be allowed to have different routing between subnets at all. Following the policy, I'm not allowed to deaggregate it at all. Even if I did, there are going to be providers who will filter everything in the space /44's are announced on the /44 boundary because "that's what ARIN says you're supposed to do". (Fair enough).
No, the proposed policy says that if you get a /44 you must "advertise that connectivity through it's single aggregated address assignment." Get a /48 from your provider? Your provider can only give /48s to organizations "through its single aggregated address allocation". Yes, if you qualify for a /32 you can break it up into /48's, but most small-medium sized hosting companies and other networks can't qualify for a /32.
True, but the smallest atomic block in IPv4 you can announce is a /24, and allocations are given in multiples of /24. In IPv6, allocations or assignments are at /48 and /44, and you must advertise the entire thing, and ONLY the entire thing.
Ok, let me explain a scenario that would directly apply to us, which probably will happen to anyone with multiple networks scattered around the globe. Lets also pretend I qualified for a /44, and received it. I have two corporate offices, one in New York and one in Los Angeles, each requiring a /48. In New York, I buy transit from ISP A and ISP B. In Los Angeles, I buy transit from ISP C and ISP D. ISP A and B don't sell service in LA. I can announce New York and LA's /48 to each provider there, but there are going to be networks out there who filter out /48's, so I need to advertise the /44 somewhere. Where do I advertise it? If I advertise the /44 in both and a single /48 only in NY, C and D are going to see our NY advertisement through whoever they're buying transit from. If their providers filter out my /48's, C and D won't see my /48 at all, so they'll send all my traffic for my NY office to LA, that I won't be able to route anywhere. If there isn't a way for end-sites to receive multiple allocations, or split their allocation up and expect 99.99% of the world to listen to their deaggregations, they can't have multiple networks. If that's the case, I think it'll encourage people to lie and try to justify multiple /44's, even though they really only need one. A company has six disconnected branch offices within the US. Which situation is optimal: 1) They somehow acquire 6 /44's, and announce 6 /44's. 2) They lie and get a /32, and announce only the 6 /48's that they really wanted, leaving the 65530 other /48's wasted. 3) They get a single /44 like they probably only really need, and deaggregate it to get 6 /44's. All three add 6 entries to your table. #1 is using /44's when a /48 would do. #2 is wasting a good chunk of space that will never be used. #3 wastes the least space, and doesn't require "creativity" in getting your allocation, but is against the current policy.
Well, I believe it does if ARIN is going to mandate deaggregation policy with their allocation policy. If they say that /44's aren't deaggregatable, providers will insist you don't deaggregate your /44. Big providers get the advantage that they can chop up their /32 however they want.
If the average hosting company did that, I think we'd run out of IPv6 before we run out of IPv4. In current IPv4 practice, it's common for hosting companies to dump racks and racks of servers into a /22 or /24-ish sized block. I could see assigning a /48 to "colo customers" and giving each one a /64 if they needed it, but a /48 each is overkill for a 1U box. Also take into account fully managed hosting providers where many customers are sharing one box, or the servers and management tasks are owned by the hosting company not the customer. I can't in good conscience claim that I need a /48 for each CUSTOMER on a shared hosting platform, which means I can't really qualify for a /32 if that's all I do. I understand what you're saying, we could claim that we're giving each customer a /48 just to get the assignment, but I don't really want to game the system. I'd rather have applications like this recognized by policy, instead of cloak & dagger stuff when it comes to documenting your network. :)
We've announced single /24's without a covering larger prefix, and have had no problems with connectivity.
I don't necessarily mind mindset changes. My concern is that people are actively doing things in IPv4 that aren't possible now in IPv6, with no workaround for a lot of these issues. However I'm much more concerned that "big" providers (anyone who can qualify for a /32) need to make nearly zero changes to their way of doing things, but Mom&Pop's regional ISP or Chuck's Web Hosting and Bait Shop are going to be losing out big when it comes to IPv6. Which is preferable, giving /32's to people who don't need anywhere near that much space so that they can traffic engineer things they way they need to, or being more flexible when it comes to deaggregation when strictly necessary? Shim6 and others are interesting, and solve multihoming issues for some, but they don't address traffic engineering or the need to do more with smaller allocations. |
- Re: Addressing versus Routing (Was: Deploying IPv6 in a d... Kevin Day
- Re: Addressing versus Routing (Was: Deploying IPv6 i... Jeroen Massar
- Re: Addressing versus Routing (Was: Deploying IPv6 i... Michael . Dillon
- Re: Addressing versus Routing (Was: Deploying IPv6 i... Andrew Dul