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

Thu Dec 22 01:33:15 UTC 2005

On Dec 21, 2005, at 1:34 PM, Jeroen Massar wrote:

> Kevin Day wrote:
> [..]
>
> I agree with your point that currently your IPv4-solution can't be
> applied to IPv6 but..(see the helpful and nice thingy part at the  
> end ;)

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)

>
>> IPv4: We split our /20 into a /23 for each city, and announce only  
>> that.
>
> This means you are taking up more routing slots. -> note the routing.
>
> The 'problem' here is that we call these allocations "IPv6 Address
> Space", not "xxx Routing Space". RIR's provide Address Space and do  
> not
> guarantee routability in any way. Hence the subject.
>
> This is actually a more fundamental problem in the current IP ideology
> than anything else.
>

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).

>
>> IPv6: We have to announce the entire /44, and aren't allowed to
>> deaggregate it.
>
> Well, that is actually not true, you can also, in IPv6, simply  
> announce
> /48's from a /32 or /44 or whatever. The same way you do that in IPv4.
>

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.

> The issue with announcing say a /48 is though that networks which  
> filter
> will filter it out and will only reach you over the aggregate. Of  
> course
> that is their choice, just like yours is to try to announce the / 
> 48's in
> IPv6, or the /23's for IPv4. An IPv4 /28 doesn't reach far either.
>

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.

> The problem here is though that your /48 will propagate through ISP's
> with less strict filters and they will act as transits for your /48.
> My experience tells that the ones not filtering also have a not so- 
> good
> setup thus your connectivity tends to go all around the world.
>

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.

>> The allocation and advertisement policies work great for small end- 
>> sites
>> (they get many subnets, and more addresses than they'll ever  
>> need), and
>> great for large providers (they have no problem justifying the  
>> need for
>> a /32, and are able to break things up if needed). If you fit  
>> somewhere
>> between those two though, I don't think the policies really  
>> address our
>> needs.
>
> Here you say it your self: "Advertisement policies" this is routing
> again, which has not much to do with Address Space.
>

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.

>> Small to medium sized hosting providers, content networks and other
>> non-bandwidth-supplying companies generally aren't providing  
>> transit to
>> others, so they can't get a /32.
>
> You don't have customers?
>
> If you have say 201 customers, who each have a 1U box in a rack you
> provide connectivity to, then give each one of them a /48, they are
> endsites and maybe that endsite sets up VPN's.
>
> As for the 201, that is what you might want to have once.
> Tada current policy fulfilled. NEXT! :)

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. :)

>
> One can deaggregate in IPv6 also, just don't expect it to be accepted.
> Just like a /24 won't be accepted by most folks.
> Also note that policy _suggests_ that one announces it as a single  
> chunk.
>

We've announced single /24's without a covering larger prefix, and  
have had no problems with connectivity.

> *** Multihoming / Route announcement trick that doesn't fill up slots
>
>  This is the very hard part. (political and technical)
>  But it might be years before we will hit the actual limits of BGP.
>  We still have to be nice to our kids though as they will hit it ;)
>
>  Currently I am aware of the following possible 'solutions':
>  - SHIM6
>  - SCTP
>  - HIP
>  - NOID
>  - WIMP
>  See:
>   draft-huston-multi6-proposals
>   draft-savola-multi6-nowwhat
>
>  Most if not all of these have problems for some uses, eg Traffic
>  Engineering is supposedly not possible anymore the way it is
>  currently being done in BGP. Mindset changes will be required.
>

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20051221/0e35b1cb/attachment.html>