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)

  • From: Kevin Day
  • Date: Thu Dec 22 14:40:30 2005

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:

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".
Please read the answer from Gert Doering to a question I posted:

This is also why I changed the subject to "Addressing versus Routing".
RIR's provide *Address Space* how the routing happens is up to you.

In IPv6, allocations or
assignments are at /48 and /44, and you must advertise the entire thing,
and ONLY the entire thing.
Why? There really won't be a single RIR going to complain to you. It is
also *impossible* for them to stop it. See also above.

The only parties that can stop it is your peers as they can filter it.
This is the same as trying to announce a IPv4 /28, if you can persuade
$world to accept it you are done. But most folks filter on /24.

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.

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.
Correct. One of the few solutions you can do is setup connectivity (VPN
or so) of your own between them. This is a routing issue. You can also
try to persuade $world to accept it.

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 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.
Why is that overkill? The person getting the /48 is an endsite and he
makes a VPN tunnel setup for all his employees from that box instead of
doing it from the 8mbit office they have.

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.

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.

(Funnily I see people complain about the current policy and limits they
"have been laid upon" but they never seem to come forward with an actual
proposal which satisfies their needs, complaining doesn't help, small hint)
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. :)