North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Addressing versus Routing (Was: Deploying IPv6 in a datacenter)
Ok, I promise this is my last reply to the list about this... This has gone too far into theoretical and not operational content, and probably belongs on an IPv6 policy list, so I'll hush. :) I'll follow up with anyone privately who wants to continue the discussion though.
On Dec 22, 2005, at 4:56 AM, Jeroen Massar wrote:
Kevin Day wrote:
In IPv6, allocations orWhy? There really won't be a single RIR going to complain to you. It is
While I really really WISH this is how it worked, my (and others I've asked) interpretation of what advertising a "single aggregated address assignment" means that ARIN does intend it to be their policy that you don't deaggregate at all. I'll email ARIN to see if I can get an official clarification. However, my opinion is that if they say "If you want IP addresses from us, you agree to do (whatever)", you'd better do what they ask. I know they can't technically prevent us from doing something in BGP, but there's a clause in the ARIN agreement that you have to sign before getting any space from them that says:
"If ARIN determines that the numbering resources or any other Services are not being used in compliance with this Agreement, the Policies, or for purposes for which they are intended, ARIN may: (i) revoke the numbering resources, (ii) cease providing the Services to Applicant, or (iii) terminate this Agreement."
So, in my book, if the RIR says I gotta do X, no matter how unfair X is, I'll do it rather than risk having them revoke my assignment. We don't want to end up in a situation where everyone is breaking the policy.
This is completely different than IPv4 though. Nothing in the IPv4 policies says anything about what announcements you can make. The "/ 24 is the smallest block that you can rely on the world listening to" policy isn't mandated by assignment policy, and it matches what the smallest block that you could get (at least, at one point, I know you can get smaller now, but it's well known that nobody will hear it).
IPv6 is new in that it does make part of the assignment and allocation policy what you do with it in BGP space, and that's what concerns me. If a new /16 were allocated specifically for /44 sized end-user blocks, and the policies stated that /44's can't be deaggregated, you know there are a good number of providers who are going to filter everything smaller than a /44 inside that /16, "because the policy says you can't do that anyway".
In IPv4, filtering on a /24 works because everything is assigned in multiples of /24's, and nearly everyone who would need to deaggregate qualifies for multiple /24 sized pieces. In IPv6, unless you're getting a /32, you're being allocated or assigned a block that can't be split up.
Yes, but that dramatically increases my expenses(I'm having to haul traffic around myself, paying for transit on it twice), and causes really sub-optimal routing. If someone else is a customer of ISP A, they're in Los Angeles and trying to reach my LA POP, ISP A is going to take their traffic all the way to New York, only for me to VPN it back to LA.In New York, I buy transit from ISP A and ISP B.Correct. One of the few solutions you can do is setup connectivity (VPN
I realize IPv6 is really big. Vastly hugely mindbogglingly big, and all that. It's so big that we don't need to worry about wasting space, which is really great in theory. But if we start assigning / 48's to every 1U box out there, regardless of need, we're going to burn through /32's faster than anyone is predicting.In current IPv4 practice, it's common forWhy is that overkill? The person getting the /48 is an endsite and he
I'm not saying a 1U box can't have a /48, I'm saying it probably doesn't need to have one automatically assigned in a hosting company environment. Assigning every 1U box you have a /48 is a great way to meet the /32 requirements, but I kinda question the necessity.
Personally, if I were doing colo or dedicated IPv6 hosting, unless the customer specified a need otherwise, groups of servers would share a /64. Customers could request a /64 of their own, or if they could demonstrate a need, get a /48.
In my defense, I wasn't even aware of the deaggregation terms in the IPv6 policy until after we started looking at IPv6 ourselves in a serious way. I agree that just complaining doesn't help, but I'm not sure I'm the right guy to do anything about it at this stage. :)