Subject: BCP for multisite multihoming

From: Kevin Day <[email-masked]>
Date: Mon, 21 May 2007 14:04:58 -0500

I ask this partly rhetorically(I think I already know the answer) and  
partly to see which alternative everyone else would use in this  
situation.

Assume the following:

1) A company has four branch offices(POPs) around the world, New  
York, London, Tokyo and Sydney.
2) This company requires IP addresses for internal use, customer use,  
etc.
3) Each POP must be multihomed, with connections to two or more  
transit providers.
4) Multihoming must support load balancing in both directions.
5) Each POP has a unique set of transit providers, there isn't one  
transit provider that has service at all locations.
6) Transit providers come and go, PA space isn't acceptable.
7) There is no connectivity between each POP at all, everything  
between nodes goes over the internet.

In IPv4 land, this company can obtain an /18, and announce a /20 from  
each POP.  Problem solved, all requirements are met.

In IPv6, which of these methods is the "right" one?

1) Obtain a single /32, and announce it at all POPs.

Not feasible - each POP would have to have enough capacity to route  
traffic for all the others. If their Sydney office is very small,  
they're going to spend a fortune just bouncing packets back out to  
the rest of the world for any traffic that hits there over tunnels or  
dedicated lines that would otherwise be unnecessary. Inbound routing  
is going to be sub-optimal. This would also be very expensive. This  
isn't necessary at all in IPv4, it's hard to justify why IPv6 would  
require end sites to handle this level of traffic routing.

2) Obtain a single /32, and announce /34s (or /36, or /40 or  
whatever, if they want to leave room for expansion) from each POP.

Probably not possible - A lot of people are filtering on the RIR's  
allocation size. If this company is assigned a /32, there's an  
expectation (correct or not) that it's the only thing going to be  
announced.

3) Obtain a single /32, announce the /32 from each POP and announce  
more specifics (/34s or whatever) to each upstream at each POP only  
for that specific POP.

Probably not possible - If your providers are also filtering on RIR  
allocation size, they aren't going to hear your more specifics from  
POPs that they don't service. Traffic is for all POPs are going to  
get pulled to a provider that may only service one provider,

4) Obtain multiple /32s, announce one from each POP.

Probably not possible - The bar is pretty high to receive a second / 
32, most companies will never reach the utilization percentage to  
receive a second, let alone one per POP.

Additional bonus semi-rhetorical questions:

* What should a company do when it requires multiple unique routing  
entries in v6 because of physical disparate networks?

* Does your solution require just as many entries in the global  
routing table as if the company deaggregated their allocation? If so,  
why not allow deaggregation where strictly needed?

* If these four offices were multiple companies instead of owned by  
the same, they'd have no problem obtaining space and announcing their  
own space at each POP. It would also equal the same number of routes  
in the table as if the one company had just deaggregated. Things are  
being complicated because they're owned by the same legal entity. One  
legal entity doesn't necessarily equal one unique network though.  
Multinational/multisite corporations are probably not going to be  
thrilled with this revelation - is this being considered acceptable  
damage?

-- Kevin
(not trying to troll here, just trying to see what the consensus is)

---

From: David Conrad <[email-masked]>
Date: Mon, 21 May 2007 12:39:45 -0700

On May 21, 2007, at 12:28 PM, [email-masked] wrote:
> 	what an egregious waste of numbering resources.

So?

You're alternative proposal is?

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 21 May 2007 13:23:06 -0700

Bill,

On May 21, 2007, at 12:57 PM, [email-masked] wrote:
>
> which problem are we "solving" here?

Well, from the subject of the message, I think it's "multisite  
multihoming".

> effective stewardship of
> Internet numbering resources or micro management of joe random's
> routing table slots?

It isn't clear to me that "effective stewardship" is a primary  
concern of either of the mailing lists the question was posted to.

> Do you disagree that  handing out /32s
> of IPv6 is an egregious waste (inefficent is not descriptive enough)
> of space?  If so, on what do you base your argument.

Irrelevant for the question being asked, however I believe the IETF  
and RIRs have spoken that address use efficiency isn't relevant with  
IPv6.

What is relevant, at least to the question asked, is under existing  
policies, your alternative proposal is?

Rgds,
-drc

---

From: Kevin Day <[email-masked]>
Date: Mon, 21 May 2007 15:26:20 -0500

On May 21, 2007, at 2:19 PM, Leo Vegoda wrote:

> On 21 May 2007, at 3:04pm, Kevin Day wrote:
>> 2) This company requires IP addresses for internal use, customer  
>> use, etc.
>
> At the point you say that they will be assigning address space to a  
> customer they become an ISP, I suppose.
>

I was trying to be general/vague enough to keep it slightly blurry  
between an ISP or end user. But sure, ISP it is.

> This seem to be four separate ISPs, in four separate continents  
> that just happen to be owned by a single organisation and possibly  
> share a brand.
>

That's one way of looking at it, sure.

>> Probably not possible - The bar is pretty high to receive a  
>> second /32, most companies will never reach the utilization  
>> percentage to receive a second, let alone one per POP.
>
> Presumably this company is incorporated in each country in which it  
> has a PoP. It is effectively four companies with a common owner. As  
> such, I think #4 is the right answer and I don't think it should be  
> too difficult to get the address space.
>

In the specific company I'm thinking of when proposing this, no,  
that's not true.

Or forget the fact that they're in separate companies, pretend it's  
one company within the US that has a dozen branch offices within the  
US. Or a hosting/colo/access company with cages in a dozen  
datacenters. Or.. whatever. :)

>
>> * If these four offices were multiple companies instead of owned  
>> by the same, they'd have no problem obtaining space and announcing  
>> their own space at each POP. It would also equal the same number  
>> of routes in the table as if the one company had just  
>> deaggregated. Things are being complicated because they're owned  
>> by the same legal entity. One legal entity doesn't necessarily  
>> equal one unique network though.
>
> Bingo!

Okay, if that's the approach you recommend, then sure. But:

Having an entire /32 per POP is tremendous overkill. And, it's still  
using just as many routes as if this company could just deaggregate  
the prefix it received. I'm also assuming that additional prefixes  
aren't going to be free, which is going to further add to the  
operating expenses of v6 over v4. It also means the company isn't  
able to tailor its space usage to each POP.

Is one allocation/assignment per site really scalable?

-- Kevin

---

From: Kevin Day <[email-masked]>
Date: Mon, 21 May 2007 15:26:19 -0500

On May 21, 2007, at 2:57 PM, Iljitsch van Beijnum wrote:

> On 21-mei-2007, at 21:04, Kevin Day wrote:
>
>
>> In IPv4 land, this company can obtain an /18, and announce a /20  
>> from each POP.  Problem solved, all requirements are met.
>
> You keep talking about /32s but what you need here is 4  
> independent /48s.
>

You need /48's up until you give access to another network and assign  
them space, then you need a /32. I was using /32s as an example of  
what would happen if this was a company large enough to be supplying  
connectivity to other entities (even if it's just smaller branches of  
their main offices, or whatever)

> However, what the internet at large needs is routing tables that  
> don't grow too large too fast. That means only a few tenthousands  
> of organizations can do what you want to do before we run into  
> trouble.
>

Well, it's not really what "(I) want to do" here, a company has a  
need for bandwidth in each of their POPs/offices/etc. They can  
accomplish this easily in IPv4, yet there's no clear way to do this  
in IPv6 that doesn't involve setting up multiple corporations to get  
multiple assignments/allocations.

> So obviously if I were you I'd get the /48s, and if I were me I'd  
> whine about the IPv6 routing table size.  :-)

If you're proposing that a company should receive multiple /48s  
instead of a /32 - isn't that causing just as much route growth?  
Isn't that also more likely to cause this company's allocations to be  
spread everywhere, instead of contiguously?

As much as we'd like to blame "the other guy" for excess routes, I  
think they fall into a few categories:

1) Leaking more specifics out of ignorance/incompetence.
2) One provider using multiple routes because they received their  
space in non-contiguous chunks.
3) Traffic engineering, such as multiple sites or complex routing  
policies.

#1 and #2 are probably going to get better, just as a result of  
having IPv6. A /32 or /48 is more than likely going to be enough for  
nearly every company out there, which is going to mean 1 prefix per  
ASN for the vast majority.

A smaller subset are going to need multiple prefixes due to #3, be it  
through deaggregation or multiple /32s or /48s. Forcing people not to  
deaggregate is only going to result in more allocations/assignments  
and mean exactly as many routes in the table at the end of the day.  
Why not skip the hassle and let providers use their own judgement  
within some reason?

In IPv4 it was decided that a /24 was the smallest block you could  
reasonably expect people to believe had a different routing  
structure, why not something similar? Let those with /32s break them  
up into /36 or /38 sized pieces? Most won't need to, and those that  
do actually do have a need for this.

-- Kevin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 May 2007 21:57:59 +0200

> from each POP.  Problem solved, all requirements are met.

You keep talking about /32s but what you need here is 4 independent / 
48s.

However, what the internet at large needs is routing tables that  
don't grow too large too fast. That means only a few tenthousands of  
organizations can do what you want to do before we run into trouble.

Iljitsch

---

From: David Conrad <[email-masked]>
Date: Mon, 21 May 2007 13:45:17 -0700

Kevin,

On May 21, 2007, at 1:26 PM, Kevin Day wrote:
> Having an entire /32 per POP is tremendous overkill.

In terms of?

> And, it's still using just as many routes as if this company could  
> just deaggregate the prefix it received.

But it is more likely those routes will actually be seen.  Given  
existing policies, if your intent is to have a multi-site multihoming  
solution and expect each site to be seen by the largest proportion of  
ASes, your options are somewhat limited.

> I'm also assuming that additional prefixes aren't going to be free,  
> which is going to further add to the operating expenses of v6 over v4.

Yep.  A tradeoff.  Obtaining a single /32 and announcing the  
deaggregates will cost you less, but you run the risk of running into  
filters.  I do not know how to quantify that risk.

> It also means the company isn't able to tailor its space usage to  
> each POP.

Not sure why not.  The fact that you have a /32 doesn't mean you have  
to use all 79,228,162,514,264,337,593,543,950,336 addresses in each  
POP.  Yes, you won't be using an absolutely insane amount of address  
space, but under existing policies, that seems to be acceptable.

> Is one allocation/assignment per site really scalable?

Nope, but that doesn't appear to be a concern any longer.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 May 2007 23:26:01 +0200

> You need /48's up until you give access to another network and  
> assign them space, then you need a /32.

So now you want one company to be 4 ISPs?? I suppose there isn't a  
law that says this can't be done but I can't say I like that.

> in IPv6 that doesn't involve setting up multiple corporations to  
> get multiple assignments/allocations.

The difference is that IPv4 is a done deal anyway, we can carry it to  
the scrap heap in 10 years time or so. However, we'll have to live  
with IPv6 for a long time.

> Isn't that also more likely to cause this company's allocations to  
> be spread everywhere, instead of contiguously?

If you don't have connectivity between your offices you'll be  
generating 4 routes anyway, whether that's 4 more specifics from one / 
32, 4 /32s or 4 /48s. IPv6 can stand some wastefulness, but 4 /32s  
seems excessive even for v6.

At this point, I guess it's time to once again point out that all of  
this could be avoided if the IETF would simply overcome its  
irrational fear of geography-related routing: http://www.muada.com/ 
drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

> 1) Leaking more specifics out of ignorance/incompetence.

The day when someone deaggregates a /32 into /48s for the first time  
will be an interesting one. I'm guessing by the end of that day  
people holding a /48 won't be too happy.

> 3) Traffic engineering, such as multiple sites or complex routing  

We need to improve BGP to give people other tools to do this.

> A smaller subset are going to need multiple prefixes due to #3, be  
> it through deaggregation or multiple /32s or /48s. Forcing people  
> not to deaggregate is only going to result in more allocations/ 
> assignments and mean exactly as many routes in the table at the end  
> of the day. Why not skip the hassle and let providers use their own  
> judgement within some reason?

Who is stopping them now?

> structure, why not something similar? Let those with /32s break  
> them up into /36 or /38 sized pieces? Most won't need to, and those  
> that do actually do have a need for this.

My rule is that you get two bits for traffic engineering. So in a  
block of address space where the RIRs take /32s from, I'd filter on  
a /34 boundary.

---

From: David Conrad <[email-masked]>
Date: Mon, 21 May 2007 14:43:38 -0700

Iljitsch,

On May 21, 2007, at 2:26 PM, Iljitsch van Beijnum wrote:
> At this point, I guess it's time to once again point out that all  
> of this could be avoided if the IETF would simply overcome its  

The IETF is mostly irrelevant in this context.  The folks who have to  
get over their fear (irrational or not) is the Internet service  
provider community.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 May 2007 23:59:55 +0200

> The IETF is mostly irrelevant in this context.  The folks who have  
> to get over their fear (irrational or not) is the Internet service  
> provider community.

The trouble is, for this to work without too much trouble, address  
space needs to be given out with geography in mind. I don't think  
IANA and the RIRs are going to do that without the IETF telling them  
it's a good idea.

(The tragedy, of course, is that even if it's _not_ a good idea, that  
merely means it's no better than what we have today, so we're doing  
what we know doesn't work because we don't want to do something else  
for which we don't know if it works or not.)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 May 2007 12:48:31 +0200

On 2007-05-21 21:04, Kevin Day wrote:
...

> 2) Obtain a single /32, and announce /34s (or /36, or /40 or whatever, 
> if they want to leave room for expansion) from each POP.
> 

I assume that money talks loud enough that this will be possible,
until there is a better technical solution, for which we have the
RAM list.

    Brian

-- 
NEW: Preferred email for non-IBM matters: [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 May 2007 10:44:29 -0400

> IANA and the RIRs are going to do that without the IETF telling them  

David said it already. The IETF won't waste it's time doing this so
long as it thinks that the proposal will go nowhere in
practice. Presumably, we all have better things to do with our time.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 May 2007 11:14:50 -0400

> whatever, if they want to leave room for expansion) from each POP.

I think this is exactly what should be done.

> expectation (correct or not) that it's the only thing going to be  

So, if people filter on /32s and that forces people to go get
additional (unjustified) /32s -- just to be able to have separate
announcements -- exactly what problem has been solved, and how have we
made the Internet scale better?

>From my perspective, one of the myths that has been propagated out of
the IPv6 address architecture is that "all deaggration is bad" and
"you MUST filter everything longer than a /32".

The original IPv6 address allocation policies were written to favor
aggregation over utilization, but an important reason for that was to
ensure that if - or when - routing tables got bloated and filtering
was necessary to keep the internet intact, one could filter the longer
prefixes without breaking overall connectivity. Yes, filtering out
longer prefixes would impact multihoming and traffic engineering, but
those are optimizations designed to create better paths for certain
traffic flows. If you filter those, you can still have overall
connectivity (via the aggregate), which is far better than NO
connectivity! Thus, the RIR policies need to ensure (to the degree
possible) that larger aggregates will always be available to cover
reachability for all should it become necessary to fliter longer
prefixes in order to keep the routing system intact.

ISPs have always been able to route/accept whatever prefixes they
want. There is no (enforceable) policy that says they MUST filter
everything longer than a /32. My sense is they are doing that today
partly as a combination of:

 - older IPv6 documents (and culture) that suggested deaggration was
   very bad and had to be avoided at all costs.

 - current operators afraid to loosen filters because they fear that
   once loosened, they cannot put the Genie back in the bottle.

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 May 2007 18:57:12 +0300 (EEST)

>> whatever, if they want to leave room for expansion) from each POP.

FWIW, at least in RIPE land, the policy still says

"... by advertising that connectivity through its single aggregated 
address allocation."

.. which IMHO requires that you must advertise the aggregate.  It may 
also be read so that you shouldn't advertise anything else than the 
aggregate but other interpretations are also possible.

Personally I don't have a huge problem with people who advertise more 
routes like above, but I do have a problem if they do not provide a 
single aggregated allocation that will provide "default" connectivity 
to operators who do filter more specifics.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 May 2007 12:06:41 -0400

> aggregate but other interpretations are also possible.

And the original intention was to ensure that an aggregate could be
advertised and that it would work. That is, one couldn't just get a
/32 and then start handing out longer prefixes to anyone who asked,
and then have those longer prefixes in effect be unroutable (because
there was no connectivity via an aggregate) with all of the individual
owners then expecting their individual prefixes to be routable.

And yes, I've heard that the above wording has been interpreted to
mean "do not deaggragate", though that was never the intention. (And,
RIRs would never agree to wording along those lines because it is out
of scope for RIR policy to tell ISPs what they can and cannot route.)

> to operators who do filter more specifics.

I think this is a much more pragmatic starting point than "do not
deaggreate, period."

Thomas

---

From: Sascha Lenz <[email-masked]>
Date: Wed, 23 May 2007 03:28:18 +0200

Hi,

> I think this is exactly what should be done.

That's what would be the ideal solution in this case, but...

> made the Internet scale better?

...even with arguments, you most likely won't get the people who DO 
filter on RIR boundaries to lower them.
Just not possible, they are stubborn and not open to arguments ;-)

So i can't really recommend to try that.

> prefixes in order to keep the routing system intact.

Right, PA-multihoming might work in most cases as long as all sites have 
a direct connectivity to the aggregate-announcing site - you just get 
worse paths from ASes which filter the more-specifics, but don't really 
loose any packets.

The only thing that does NOT work is real independence from the 
aggregate-announcing entity.
For example, a very small ISP, or probably a non-commercial organisation 
  who doesn't want to become a RIR member or doesn't qualify for a /32 
PA block won't have that much fun with a sub-allocation from an existing 
RIR member and different upstreams.

That's bad, bad, bad to some extent since not even "PI" space helps much 
here if they want to sub-assign space to members or customers.
That again this will result in the IPv4-like behaviour that they just 
get multiple /48 PI nets for all customers/members instead of a single 
/40 PA sub-allocation in some cases, which is the exact difference of 
what is desired.

The same goes for those cases like here where you have a split network...
You need multiple /32 PA blocks or multiple PI blocks to get real 
working independence. Routing-wise, both costs the same.

(DISCLAIMER: I strongly support the course that everyone who wants to 
ASSIGN address space should become a RIR member, but that just doesn't 
cover the real world behaviour/requirements in all and every case)

> partly as a combination of:

Of course not, routing is decentralized. You can't do anything against 
that policy-wise.
Just look that the problems de-bogonizing IPv4-/8s or nowerdays even new 
IPv6 blocks which are not 2001::something ...

>    once loosened, they cannot put the Genie back in the bottle.

yep, that's pretty much the case.
And i don't really see a solution here exactly for the latter reason.

-- 
========================================================================
= Sascha Lenz                  SLZ-RIPE          [email-masked]         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 May 2007 10:08:29 +0200

Hi,

> Is one allocation/assignment per site really scalable?

Regarding address space usage, yes.  (Because a /32 more or less does
not really make any difference anywhere.  Even burning a million /32s 
isn't going to bring us anywhere near *address space* shortage issues.
[OK, come flame me.  *I* can do maths.  Can you?]).

Regarding routing table: it doesn't make a difference what you do 
("own /32, deaggregated single /32, PI networks") - with current 
routing technology, you end up with one routing table slot per location.
Which is not perfect, but as long as it stays at *one* prefix per 
location, it's still better than most IPv4 setups that outgrow their
initial prefix over time, and need to add more prefixes later on.

So - in the current policy and routing framework, my answer would be:

 - if this is ISP-like business, go for a /32 for each location, and 
   happily assign from that to the local customers

 - if this is a "enterprise-like" business, go for a /48 PI for each
   location [which might not be possible in each region]

 - if this is in between (datacenter, etc.), chose what model fits best

If the local policies do not permit multiple /32s for a "single enterprise",
either work on changing the policies (similar to the ARIN IPv4 policy about
disconnected networks being entitled to multiple allocations) or have each
local organization become a RIR member ("LIR" in RIPE land) of its own.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 May 2007 10:17:48 +0200

Hi,

On Mon, May 21, 2007 at 04:35:20PM -0400, Leo Vegoda wrote:
> Yes, a /32 is far more than many sites will need.
> 
> The first requires a new, scalable approach to routing and the latter  
> can be solved by changing the minimum allocation size. The latter is  
> relatively easy.

Technically, this is the wrong forum, but I want to make this heard
anyway.  I consider every thought of reducing the /32 to a smaller 
minimum allocation size fundamentally flawed - this is IPv4 thinking.

IPv6 allocation policies should aim at

 - a single enterprise should be happy with a *single* IPv6 prefix,
   for as long as the network exists  (so it needs to be big enough for
   your typical small-to-medium sized ISP - and a /32 just meets that)

 - it is not much use to squeeze out address space on things that need to 
   go to the routing table anyway (ISP prefixes, that is) - what do you win 
   if you force /40s on ISPs, and then end up with 99% of the address space
   unused because your routing table cannot take more entries?

   Giving /32s to ISPs means, theoretically, 500 million /32s out there -
   which everybody agrees that routers cannot take.  So, reducing this to
   "smaller blocks", whill indeed save space - but what can you use it for?

The /32s are already a compromise, and as soon as an ISP has an internal
network hierarchy, needs to do internal aggregation etc., this isn't so
spacious anymore.  I would have preferred a /28 or similar "no questions
asked".

Please stop thinking in IPv4 trains.

The real question is "who needs/deserves a global routing table slot", 
not "how many bits can you haggle for".

Gert Doering
        -- RIPE APWG chair

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 May 2007 10:10:30 +0200

On 2007-05-23 03:28, Sascha Lenz wrote:
...
> Just not possible, they are stubborn and not open to arguments ;-)

They are open to arguments accompanied by large amounts of money,
This is a business issue, not a technical or religious issue.
When there are financial incentives to relax the filters, it will
happen.

BTW the same is true of geographic addressing - as Iljitsch
says, it isn't hard technically. What has been lacking for the
last 15 years is a financial incentive.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 May 2007 11:55:13 +0200

> [OK, come flame me.  *I* can do maths.  Can you?]).

Ok, I can't resist that one...

Randy doesn't seem to think I can. And with the sorry state of  
education these days, a computer science degree doesn't guarantee  
anything, either... So proceed at your own risk.

IPv6 is 128 bits long. We used up 64 bits for stateless autoconfig.  
We used another 16 bits up for subnetting. If we then use up another  
16 bits to arrive at a common minimum allocation size, we're left  
with 32 bits, the same number that is proving problematic with IPv4.  
The difference is that with IPv4, many sites need much more than a  
single /32 while with IPv6, it's a /32 per site according to the  
logic presented in this discussion.

Obviously, the IPv6 address space can stand to lose a few /32s here  
and there, as there are 536 million of them available. But a year  
ago, some people made the case that with many levels of hierarchy,  
we'd get pretty close to the limits of what IPv6 has to offer under  
current policies. I.e., we have 29 bits, applying a 80% HD ratio this  
means we'll effectively be able to use only 9.6 million /32s. The HD  
ratio doesn't apply wholesale here, as there will be significant flat  
routing, but considering that there are 1.4 million businesses in the  
Netherlands alone, I'm thinking we can screw this up if we try hard  
enough and take enough time to do it.

(75000 of those business have at least 10 people working there. NL is  
about 0.25% of the world population so the world figure for 10+  
business could be in the order of 30 million.)

So giving away /32s when something smaller would do isn't the  
greatest idea ever.

And you can't ignore the routing issue. If you could, we'd do flat  
routing on individual IP addresses and IPv4 would last until the the  
3.7 billionth user connects to the network. Let me quote a few lines  
from the IPv4 routing table to show you why relaxed filters are not a  
good idea:

    Network          Next Hop            Metric LocPrf Weight Path
*> 12.201.48.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.50.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.52.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.56.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.58.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.60.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.64.0/21   12.0.1.63                              0 7018 6478 i
*> 12.201.72.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.74.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.76.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.78.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.80.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.82.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.84.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.88.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.90.0/23   12.0.1.63                              0 7018 6478 i
*> 12.201.92.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.96.0/22   12.0.1.63                              0 7018 6478 i
*> 12.201.100.0/23  12.0.1.63                              0 7018 6478 i
*> 12.201.102.0/23  12.0.1.63                              0 7018 6478 i
*> 12.201.104.0/23  12.0.1.63                              0 7018 6478 i
*> 12.201.106.0/23  12.0.1.63                              0 7018 6478 i

(It goes on like this for another 1100 lines, about the size of the  
entire IPv6 routing table.)

Since we obviously can't depend on the address space holders to do  
the right thing, it's necessary to filter. A good filter catches  
everything that's in the routing table by mistake, and allows  
everything that's in there by design. Unfortunately, today's policies  
and practice don't make this very easy, for two reasons:

1. PA assignments are (often) /48s, same thing for PI blocks, so it's  
not possible to see the difference between leaked PA deaggregates and PI

2. /32 and larger allocations are made from the same bunches of  
address space. This means that someone with a /21 can inject 2048 / 
32s. However, due to the HD ratio, people can get a /21 if they need  
around 450 /32s. So giving out larger blocks to aid aggregation can  
actually make deaggregation worse.

Fixes:

1. Make PI blocks a different size than PA end-user assignments. /44  
makes sense, this is a good deal bigger than /48 so even fewer people  
are going to need more and it's on a nibble boundary for easy DNS  
delegation and no need to reserve for growth. Filtering could happen  
on /47 which rejects leaked /48s but allows 3 bits for traffic  
engineering

2. Make all allocations from a given block of address space the same  
size, so there would be ranges for /32s allocations, for /28  
allocations, /44 assignments, etc.

> location,

Oh, now we're doing a PI block per location? I'm guessing a PI block  
per plane is next, then one per car, one per mobile phone... After  
all, I don't want to have to renumber when I take my laptop from home  
to work.

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 May 2007 13:47:33 +0200

Hi,

> Ok, I can't resist that one...
[..]
> and there, as there are 536 million of them available. But a year  
[..]
> enough and take enough time to do it.

You missed my point.  My point wasn't "we can afford to give anyone
that comes a /32" - it was "for the number of routes that we can afford,
it doesn't make a (big) difference whether it's a /32 or a /40, because 
this is not going to use up all the available space anyway".

Indeed we can *not* affort "a globally visible route for every 'business'
in the world".

[..]
> and practice don't make this very easy, for two reasons:

A *good* filter is one that permits exactly what is supposed to be there
(as documented in a routing registry) and nothing else.  This is perfectly
well doable towards customers, and mostly doable towards peers.

Heuristics only work, well, by chance.

> not possible to see the difference between leaked PA deaggregates and PI

Indeed it is, as the RIRs take good care to set aside specific blocks
for special-case prefixes (PI, IXP, ...).  It's a bit time-consuming to
always figure out which block is what, but it can be done.

> actually make deaggregation worse.

Indeed.  If one assumes that those enterprise have nothing better to
do than to deaggregate to /32s.

> on /47 which rejects leaked /48s but allows 3 bits for traffic  

See my comment to "1." above - this is a solution in search of a problem :-)

Doing this has another drawback: it makes PI more attractive to end sites
than PA ("I can get a bigger address block with PI!!!") - which is not
what we should aim for.

(We already have this, with the new approach "end users can get anything
between /64 and /48", but as the policies still permit /48s to be given
out to end sites "no questions asked", it's not that bad yet)

> allocations, /44 assignments, etc.

Given the sheer and overwhelming amount of bigger-than-/32 allocations,
filtering these ranges explicitely is not a seriously big deal.

> all, I don't want to have to renumber when I take my laptop from home  

I was responding in a very specific context.  If you don't want to consider
my comments *in the context of the given question*, then please don't 
bother answering to them at all.

I explictely wrote "in the current policy and routing framework" as 
a preface to this answer - and there is no other answer.

Gert Doering
        -- NetMaster

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 May 2007 14:28:56 +0200

On 23-mei-2007, at 13:47, Gert Doering wrote:

>> considering that there are 1.4 million businesses in the

> this is not going to use up all the available space anyway".

Ok.

Wouldn't it suck, though, if through some herculian effort, we'd be  
able to make routing scale, and then we run out of address space?

>> A good filter catches
>> everything that's in there by design.

> (as documented in a routing registry) and nothing else.

That is one thing that you may want to design your filter for, yes.

> always figure out which block is what, but it can be done.

True. But being able to reject leaked PA without having to hunt for  
special case blocks on the various RIR sites would be better.

> do than to deaggregate to /32s.

Experience with IPv4 shows that some people indeed do this. And if  
you have a /21 for world-wide use, do you really want to receive your  
traffic for Nigeria in Hong Kong? Or would you want to advertise more  
specifics in various locations?

> See my comment to "1." above - this is a solution in search of a  

This would also help with PA multihoming.

> than PA ("I can get a bigger address block with PI!!!")

As if you can't get more than a /48 from an ISP... I currently have  
a /48 for use at home and another /48 for my colocated server.

> filtering these ranges explicitely is not a seriously big deal.

At least keeping the bigger blocks out of the /32 pool would be a start.