Subject: Re: v6 multihoming and route filters

From: Marc Blanchet <[email-masked]>
Date: Mon, 3 Jul 2006 13:02:32 -0400

with this draft-ietf-v6ops-routing-guidelines draft, we could:
a) do not mention anything about maximum unicast prefix length
b) mention that the very maximum unicast prefix length is /48, but  
should be smaller and refer to right documents/policies
c) go into debate on what would be the maximum prefix length, /47, / 
46, /44, 40, /36, /32, /...

first (personal) draft was b) and I still believe it is the best we  
can do for now than don't say anything like a).  if ARIN policy is  
implemented as it seems to be, we will end up with b). b) does not  
harm anyone, it is just stating the bare minimum.

so to me, b) should be back in the draft.

Marc.

Le 06-06-29 à 00:45, Pekka Savola a écrit :

> On Wed, 28 Jun 2006, Azinger, Marla wrote:
>> I ask the V6 WG to create a "best practice for multihoming" that  
>> can be utilized today.  I ask that you please insert the solution  
>> to filter at /48 thus allowing "upstream providers" to provide  
>> multihoming to their customers.  This solution is needed to  
>> support providers creating V6 networks and this solution can  
>> easily be added into Marc's "IP V6 Routing Policy Guidelines"  
>> document.
>
> This is unlikely to get traction in the WG.  The initial draft was  
> basically like that but was changed. Many people (myself included)  
> opposed (and will oppose) recommeding opening filters up to /48.
>
> Let's not create a swamp out of v6 address space with more specific  
> junk.
>
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

=========
IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca

---

From: Kevin Loch <[email-masked]>
Date: Mon, 03 Jul 2006 14:46:20 -0400

Marc Blanchet wrote:
> c) go into debate on what would be the maximum prefix length, /47, /46, 
> /44, 40, /36, /32, /...
> 
> first (personal) draft was b) and I still believe it is the best we can 
> do for now than don't say anything like a).  if ARIN policy is 
> implemented as it seems to be, we will end up with b). b) does not harm 
> anyone, it is just stating the bare minimum.

There are already direct /48 assignments for critical infrastructure so
ARIN PI /48's will not be the first, but it may get confusing if 
different RIR's make RIR assignments in an ad hoc manner.

Hopefully the RIR's and IANA will set use space from a designated /16 
for any PI end site assignments they make to simplify filtering to make 
is more idiot-resistant.  Perhaps a draft should be written to recommend 
this. Sure, a /16 is much more space than is needed but most of it would 
remain reserved as it is today.  It might also be desirable to use space
from this /16 the future for non-BGP PI solutions that involve making 
assignments.

On the subject of route filtering, it's not a simple as "here is the
limit, this is ok and this is not".  There are different consequences
for prefixes accepted vs those originated or readvertised.

Here is a possible filtering recommendation which uses the
"be conservative in what you send but liberal in what you accept"
philosophy and covers the various situations:

Received:
- Routes from customers:  Operators may accept any prefixes from
   customers, if the prefixes (or parent) are delegated to the customer.
- Routes from peers/transit:  Operators may accept any prefixes from
   peers/transit they want, and may reject any prefixes they don't want.
   it is recommend they not accept prefixes longer than /48.

Announced:
- Routes originated by an ASN:  Operators should whenever practical
   minimize the number of prefixes they originate, ideally only the exact
   prefixes delegated by an RIR.  Steps must be taken to prevent
   unintentional origination of more specifics.
- Routes originated by an ASN and announced to an upstream provider:
   Prefixes of any length  may be advertised to an upstream but steps
   should be taken by one or both parties to prevent prefixes longer than
   /48 or unintentional deaggregates from being readvertised.
- Routes readvertised by an ASN:  Operators should (must?) not
   readvertise any prefix longer than /48.

- Kevin

---

From: "Stacy Taylor" <[email-masked]>
Date: Mon, 3 Jul 2006 14:24:58 -0700

Hi Kevin,
ARIN Policy Proposal 2005-1 does indeed include this:
"These assignments shall be made from a distinctly identified prefix."
It does not specify they size of the PI pool, though.  To be clear,
are you suggesting a /16 be reserved by the IANA for this purpose?  Or
do you see each region deciding on the size of its own pool?
As a point of reference,  ARIN and AfriNIC are the only two regions
with end site PI allocation policies at this time.
Cheers,
/Stacy

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 03 Jul 2006 23:40:00 +0200

Hi Stacy,

I guess something has been confused here ...

AfriNIC has not IPv6 PI allocation policy in place, there is a proposal,
which I've submitted (as I did in APNIC, LACNIC and RIPE NCC). They are all
under discussion.

I'm not really sure, in case the PI policies are accepted, in other regions,
to use the same reserved prefix ...

Regarding a previous email I've seen before, I've seen /48 assigned to
critical infrastructures being filtered and tried to fix it with several
(even big) telcos and didn't worked. That's why my proposal has been always
if we go for this kind of PI policy, to use a /32.

As an example, I know about someone having a /32 an announcing it as 2x/33
and being filtered one day after other ...

Regards,
Jordi

> De: Stacy Taylor <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 3 Jul 2006 14:24:58 -0700
> Para: Kevin Loch <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: v6 multihoming and route filters
> 
> Hi Kevin,

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Stacy Taylor" <[email-masked]>
Date: Mon, 3 Jul 2006 17:05:10 -0700

Hi Jordi!
Of course you are on top of it! Would you be so kind as to update this
list with events in the policy proposal cycles?  I feel it's very
germane to our discussion.  I'll be happy to continue with ARIN region
stuff if you'd like.
Thanks,
/Stacy

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 4 Jul 2006 07:48:37 -0400

> for prefixes accepted vs those originated or readvertised.

sure, that is the whole idea of the draft.

> philosophy and covers the various situations:

ok. I agree in principle on what you wrote below. I see from your  
contributed text below two concepts:
a) "generic"/well-known filtering recommendations (applicable to v4 too)
b) specific to ipv6 around "no longer than /48"

I was not going too much around a) because a) is covered elsewhere.
What is on debate is b). And again, b) is what I'm proposing since  
the first (personal) version of the draft:
- filter/do not advertise any prefix longer than /48.

If we agree on this (filter/do not advertise any prefix longer than / 
48), than I'll put it back into the draft!

Marc.

=========

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Jul 2006 22:59:56 +0200

On 4-jul-2006, at 13:48, Marc Blanchet wrote:

> And again, b) is what I'm proposing since the first (personal)  
> version of the draft:

> If we agree on this (filter/do not advertise any prefix longer  
> than /48), than I'll put it back into the draft!

What would be the purpose of filtering at /48?

That allows for 2^45 = 351 trillion prefixes in the routing table,  
which I suspect won't work too well on current routers. And it only  
takes a handful of /32s deaggregated into /48s to inflate the IPv6  
global routing table to a size larger than the current IPv4 routing  
table.

So filtering at /48 really doesn't buy you anything, either you don't  
care and/or you have large routers and then prefixes longer than /48  
won't make much of a difference, or you care and/or you have small  
routers and then /48 is too much already.

And in theory, anycast addresses should be announced into inter- 
domain routing (when the anycast group spans ASes) as /128s... Or  
maybe that one has been removed in an update of the RFC in question,  
not sure.

By the way:

mysql> select count(*) from addrspace where type='ipv6' and num > 35;
+----------+
| count(*) |
+----------+
|      137 |
+----------+

mysql> select country, descr as prefix, num as pfxlen from addrspace  
where type='ipv6' and num > 35 and not descr like "2001:7f8:%" and  
not descr like "2001:504:%" and not descr like "2001:503:%";
+---------+------------------+--------+
| country | prefix           | pfxlen |
+---------+------------------+--------+
| JP      | 2001:7fa::       |     64 |
| HK      | 2001:7fa:0:1::   |     64 |
| KR      | 2001:7fa:0:2::   |     64 |
| JP      | 2001:7fa:0:3::   |     64 |
| TW      | 2001:7fa:1::     |     48 |
| ID      | 2001:7fa:2::     |     48 |
| NZ      | 2001:7fa:3::     |     48 |
| NZ      | 2001:7fa:4::     |     48 |
| CN      | 2001:7fa:5::     |     48 |
| VN      | 2001:7fa:6::     |     48 |
| JP      | 2001:7fa:7::     |     48 |
| KR      | 2001:7fa:8::     |     48 |
| AU      | 2001:7fa:9::     |     48 |
| AU      | 2001:7fa:a::     |     48 |
| AU      | 2001:7fa:b::     |     48 |
| AU      | 2001:7fa:c::     |     48 |
| AU      | 2001:7fa:d::     |     48 |
| AU      | 2001:7fa:e::     |     48 |
| ID      | 2001:7fa:f::     |     48 |
| CN      | 2001:7fa:10::    |     48 |
| US      | 2001:500::       |     48 |
| US      | 2001:500:1::     |     48 |
| US      | 2001:500:2::     |     48 |
| US      | 2001:500:3::     |     48 |
| US      | 2001:500:4::     |     48 |
| US      | 2001:502:100e::  |     48 |
| US      | 2001:502:2eda::  |     48 |
| US      | 2001:502:4612::  |     48 |
| US      | 2001:502:7a71::  |     48 |
| US      | 2001:502:ad09::  |     48 |
| US      | 2001:502:cfb5::  |     48 |
| US      | 2001:502:d399::  |     48 |
| US      | 2001:502:f3ff::  |     48 |
| BR      | 2001:12f8::      |     48 |
| AR      | 2001:12f8:1::    |     48 |
| CO      | 2001:12f8:2::    |     48 |
| MX      | 2001:12f8:4000:: |     48 |
+---------+------------------+--------+
37 rows in set (0.16 sec)

> IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca

Mine is published by Apress, see http://www.runningipv6.net/  :-)

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 4 Jul 2006 19:04:45 -0400

> What would be the purpose of filtering at /48?

- simple: through out anything longer: so /64, /56 will be filtered.  
end of it.

> global routing table to a size larger than the current IPv4 routing  

the fact that I'm suggesting to filter at the /48 level is just that  
I don't know how to build a concensus right now on another more  
restrictive boundary.  for the global routing table perspective, I  
would love to recommend /32 or smaller, but I'm not sure we can get  
that agreement.

have you read the first version of the draft (draft-blanchet-v6ops- 
ipv6-routing-guidelines-00.txt?

>
> So filtering at /48 really doesn't buy you anything,

yes, see above: filtering any /56 or /64 or /127 or ...

Is my point clearer?

Marc.

> either you don't care and/or you have large routers and then  
> prefixes longer than /48 won't make much of a difference, or you  
> care and/or you have small routers and then /48 is too much already.
>
> maybe that one has been removed in an update of the RFC in  
> question, not sure.
>
> By the way:
>
> mysql> select country, descr as prefix, num as pfxlen from  
> addrspace where type='ipv6' and num > 35 and not descr like  
> "2001:7f8:%" and not descr like "2001:504:%" and not descr like  
> "2001:503:%";

=========

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jul 2006 01:36:14 +0200

> - simple: through out anything longer: so /64, /56 will be  
> filtered. end of it.

Sure, but why is that a good thing?

> the fact that I'm suggesting to filter at the /48 level is just  
> that I don't know how to build a concensus right now on another  
> more restrictive boundary.  for the global routing table  
> perspective, I would love to recommend /32 or smaller, but I'm not  
> sure we can get that agreement.

Well, if you look at:

http://www.arin.net/policy/nrpm.html#ipv6

You'll see:

6.4.3. Minimum Allocation

RIRs will apply a minimum size for IPv6 allocations, to facilitate  
prefix-based filtering.

The minimum allocation size for IPv6 address space is /32.

So this should be a no-brainer...

I don't think it's a good idea for the IETF to publish a document  
with recommendations unless those recommendations are clearly a good  
idea to follow today, and for some years to come. Once an RFC is  
published, it never goes away, so we should be careful about putting  
stuff in there that is likely to be outdated within the forseeable  
future.

> ipv6-routing-guidelines-00.txt?

http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-ipv6-routing- 
guidelines-00.txt doesn't seem to exist.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 4 Jul 2006 18:12:40 -0700

> global routing table to a size larger than the current IPv4 routing

But then, filtering at /32 allows for 2^30 = 1 billion prefixes, which I
suspect also won't work too well on current routers. Setting filtering
constraints at /32 is not sufficient to ensure small tables.

Setting narrow filtering constraints is also counter-productive, as it
encourage a rush on the short prefixes. An organization that could have
done just fine with a /48 or maybe a /40 will request a /32 just in
case, so that organization can eventually multi-home. 

In the end, the size of the routing table will equal the number of
entities that want multi-homing hard enough. Playing around with prefix
sizes will not change that, and will probably generate undesirable
counter effects.

Besides, there are networks in which advertizing /48 or even /64 in BGP
makes perfect sense. Take for example the "metropolitan aggregation" in
which all users in an area get numbered from the same long prefix. The
local ISP will have to exchange the short prefixes with each other. The
will use BGP. Do we want to have a rule cast in stone that prevents
them?

We should really think twice before asking the IETF to publish a
position on this subject. Silence may well be the right approach.

-- Christian Huitema

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 4 Jul 2006 21:46:33 -0400

> constraints at /32 is not sufficient to ensure small tables.

yeap.

> will use BGP. Do we want to have a rule cast in stone that prevents

fine. however, the "global routing table" should not see these. Hence  
back to the minimal requirement to filter at least anything longer  
than /48.

> position on this subject. Silence may well be the right approach.

I think it is reasonable and good stewardship to define the longest  
prefix possible in the global routing table (/48). Then anything  
smaller is subject of policies and is probably more contentious to  
write.

Marc.

=========

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Jul 2006 07:55:30 +0300 (EEST)

On Tue, 4 Jul 2006, Marc Blanchet wrote:
> I think it is reasonable and good stewardship to define the longest prefix 
> possible in the global routing table (/48). Then anything smaller is subject 
> of policies and is probably more contentious to write.

Stewardship of who?  The IETF is not the steward of address 
allocations, so it has been rightfully argued that the IETF is not 
necessarily the steward of the operators of those allocations either.

As there is no consensus on what this should include, the most the 
IETF could do (IMHO) is describe the tradeoffs of different filtering 
schemes.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jul 2006 10:28:01 +0200

> suspect also won't work too well on current routers.

Yes, that's true. But a billion is still a lot closer to something  
reasonable than another nearly six orders of magnitude. And the  
crucial difference is that there is little chance of the the full ::/ 
3 space being deaggregated into individual /32s, while leaking of  
significant numbers of "private" /48s into the global routing table  
is something I fully expect to happen based on experiences with IPv4.

> case, so that organization can eventually multi-home.

This assumes that people will get anything they request. Currently,  
you can't really get a /40: ISPs get /32 or shorter, end-users rarely  
get something shorter than /48.

> position on this subject. Silence may well be the right approach.

On the other hand, no filtering at all is asking for trouble, so it  
would make sense for us to come up with a good filtering strategy.  
One would be to make a filter based on actual allocations, which is  
still possible in IPv6 today because of the small size of the global  
table.

Another approach is to filter on prefix size depending on the size of  
the prefixes RIRs give out in a certain part of the address space.  
(Possibly allowing one or two extra bits for traffic engineering  
purposes.) I think this is the best way to do it currently, but the  
problem is that the RIRs are still coming up with new stuff here so  
if we write this up it's likely that the list of parts of the address  
space where /48s are given out will change soon after, so the  
resulting document won't be all that useful in practice. (I'm also  
VERY much annoyed by the fact that the RIRs say you can filter on /32  
(see quote yesterday) but give out /48s at the same time, I've  
brought this up YEARS ago and no action so far. The fact that each  
RIR reinvents the wheel with little global coordination but we're  
dealing with a GLOBAL routing table and not several regional ones  
doesn't help.)

Third approach: use prefixes shorter than /48 for anything that  
should be in the routing table and then filter at /47. This avoids  
problems with accidental leaking of /48s from internal routing, but  
the ship has sailed on /48 for "micro allocations" so this approach  
would have to be combined with the previous one.

Finally, it would be possible to tag prefixes longer than /32 that  
are injected into global routing intentionally, especially in the  
case of shorter prefixes that are drawn from a larger address block  
for multihoming purposes, with a BGP community that indicates why  
this is done so that people can filter appropriately. For instance,  
as a network operator I may want to allow such prefixes from "close  
by" but not from other continents, so that there is a more or less  
dynamic tradeoff between routing table size and optimum traffic flow  
through the network, which is really what we want. (With PI you're  
forced to carry the route or the destination is unreachable, not a  
very nice choice.)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 7 Jul 2006 19:05:58 +0200

> position on this subject. Silence may well be the right approach.

I am with Christian here. The existence of a prefix of a given length  
in the routing table is dependent on someone deciding this prefix  
precious enough to accept it. If we take v4 history as an example  
both Verio and Sprint used to have extremely tight prefix filtering  
in place. AFAICT not any more. At the end of the day  - revenue wins.

I think we should simply leave prefix recommendations out. No prefix  
allocated or assigned by the RIRs is guaranteed routability....

- kurtis -

---

From: Fred Baker <[email-masked]>
Date: Sat, 8 Jul 2006 14:45:29 -0400

> sure we can get that agreement.

I'm not in the middle of ARIN etc, and frankly think they know their  
business better than I know their business. Consider this my two yen  
from a distant part of the peanut gallery.

That said, the counterpart here is to say that a typical business  
gets a /28 IPv4 prefix (or whatever it gets), so the obvious BGP  
filter level is /28 in IP. That's no a meaningful recommendation,  
even if it was acceptable - you're never going to get anything  
smaller than that in the first place.

In the IPv4 world, the guideline is generally that one filters to the  
allocation level (/20 or /19 or whatever - it changes) and goes for a  
longer one only if one has a business reason to do so. AFAIK, the  
counterpart in IPv6 is a /32. So it seems like the initial  
recommendation for IPv6 should be as it has indeed been - that one  
filter to the allocation level unless one has a business reason to  
accept a longer one.

If the operational community wants to split the difference somewhere,  
so be it. I could imagine a /40 if the operational community decided  
that scaled adequately for their needs. But if you're filtering at / 
48, there is no point in filtering.