Addressing versus Routing (Was: Deploying IPv6 in a datacenter)

Thu Dec 22 19:39:00 UTC 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:
> http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2005/msg00488.html
>
> 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. :)