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

Thu Dec 22 10:56:07 UTC 2005

Kevin Day wrote:
> 
> On Dec 21, 2005, at 1:34 PM, Jeroen Massar wrote:
> 
>> Kevin Day wrote:
[..]
> 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)

Well that part is only of interest to the transit companies ;)
The part that is important is that usually the 'smaller' parties bring
content and content (Web,GamingServices,and a lot more) is something
that IPv6 still needs for quite a bit.

[..]
>> 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".

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.

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

At least RIPE also gives out /26's on request, eg if you need globally
unique address space but don't want to route it anyway.

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

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

(Which is what the current policy calls end-sites btw ;)

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

To demonstrate how far the filtering is being done, check:
http://www.sixxs.net/tools/grh/lg/?show=endsite&find=::/0

This shows /48's, out of a larger /32 (or more) that are being announced
by a different ASN than the ASN that announces the DFP. (/48 being
announced by the same ASN should IMHO get aggregated). afaics this
matches your above described LA/NY setup. The above shows 70 prefixes at
the moment btw. I expect there to be a couple more but those are then
usually using the same ASN to announce the more specific, which is not
'true bgp multihomed' imho.

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

With current filtering policies both a /48 and a /44 will be accepted by
the most clueful sites.

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

6 offices, 150 employees in total, add expected growth for the
forseeable future, say +50 employees, they all need a VPN => 206.

> 3) They get a single /44 like they probably only really need, and
> deaggregate it to get 6 /44's.

6 /48's you mean ;)

> All three add 6 entries to your table.

Which is where the 'big problem' lies for some people, for the
foreseeable future (say coming 25 years) this will go fine, but after
that will it still go fine?

[..]
>>> 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.

Please take a look at http://www.sixxs.net/tools/grh/dfp/all/ and try to
spot some places which have "very large networks".

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

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

That is true indeed.

[..]
>> 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. 

Daniel Roesen wrote:
> Uhm, sorry, but that's wrong. /24s are widely(!) accepted and only very
> seldom not accepted. There are many (MANY!) folks running on /24 PI
> (== no larger covering aggregate) without problems.

Oops I meant to type "smaller than /24" (thus /25's, /26's etc) :)

The point I intended to make: ISP's make the policies in what they
accept, not the RIR's.

To put it in reverse, ask Daniel (in an off list message) how much work
he had to do to get a certain large prefix to actually being accepted at
most sites in the DFP. There are also sites that filtered on larger than
/32.

This is similar to Bogon Prefix filtering where ISP's don't update the
filters.

Kevin Day wrote:
[..]
> 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.

If you see these issues then participate in the SHIM6 working group and
explain these issues and suggest how you can solve them. Just like the
RIR's, IETF has an open process and anybody can participate. But do
bring valid justifiable arguments.

Daniel Roesen wrote:
>>  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 ;)
>
> Really? Where are the limits of BGP? Can you show me any numbers?
> You'd be the first. I'm not aware of any protocol inherent scaling
> brickwalls like with other protocols where certain timing constraints
> place limits (or thinking of L1 systems, you remember CSMA/CD?).
> That doesn't mean that there are none - I'm not a scientist or
> mathematician - I'd be happy to have any numbers to back the FUD about
> the end of world being near. :-)

Which part of "it might be years before we will hit" did you ignored? :)

But as we had a nice example above (LA/NY office), lets that that.
Lets say we have 1.000.000 companies, they all have say 10 offices, thus
they all want to announce separate /48's, that brings us to 10.000.000
/48's. Do you have equipment to support that? Current IPv4 BGP contains
about 170k prefixes. And remember that it might just be that say 500k
routes suddenly all change because they are actually going over the same
transit who has a failure somewhere.

Indeed that will not happen tomorrow and not even in the coming 25 years
but will most likely happen later on.

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

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20051222/7e5f4cf4/attachment.sig>