Subject: RE: v6 multihoming and route filters

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 5 Jul 2006 09:12:13 -0700

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

I know we had/have prefix leaks with V4, but doesn't anyone think we as a community have learned the value in not leaking by now?  If we have lots of offenders like this, are they large Upstream providers?  Or are they small End Users or ISP's that may not ever renumber into V6?  I am curiouse how much we think this V4 problem really will be with V6.

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

I understand this frustration.  However, the policy put forward so far has been done without any guidance from IETF to be taken into consideration.  With some written guidance to consider it is very possible policy can be adjusted and new policy can be made to follow the guidance.

Marla Azinger
Frontier Communications

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Iljitsch van Beijnum
Sent: Wednesday, July 05, 2006 1:28 AM
To: Christian Huitema
Cc: Marc Blanchet; [email-masked]
Subject: Re: v6 multihoming and route filters

On 5-jul-2006, at 3:12, Christian Huitema wrote:

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

> But then, filtering at /32 allows for 2^30 = 1 billion prefixes,  
> which I
> 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.

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

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.

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

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: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jul 2006 21:09:30 +0200

> I know we had/have prefix leaks with V4, but doesn't anyone think  
> we as a community have learned the value in not leaking by now?

Sure, but that doesn't mean it can never again happen.

> If we have lots of offenders like this, are they large Upstream  
> providers?  Or are they small End Users or ISP's that may not ever  
> renumber into V6?  I am curiouse how much we think this V4 problem  
> really will be with V6.

Currently, there is no mass deployment of IPv6, so even if at some  
point an AS leaked all its internal routes, this would probably not  
have been all that many at this point.

I'm not as worried as I was with IPv4, because I think we really did  
learn something, but I would still not feel comfortable allowing /48s  
without limitation. As I wrote before, a mechanism where routes that  
are allowed out on purpose are tagged so that they can be recognized  
as such could make all the difference here. In certain setups, it's  
very easy to make a mistake that allows routes through that are  
supposed to be filtered out as allowing routes through is the  
default. But inappropriately tagging routes with a BGP community by  
accident is much harder because the default is not having the tag.

>> (I'm also

> I understand this frustration.  However, the policy put forward so  
> far has been done without any guidance from IETF to be taken into  
> consideration.

I'm not so sure; filtering on /32 is pretty much on par with the  
6bone routing guidelines that came from the IETF. The document I  
referred to was also orignally adopted by all the RIRs and IANA  
(which is now part of ICANN but used to be much closer aligned with  
the IETF).

> With some written guidance to consider it is very possible policy  
> can be adjusted and new policy can be made to follow the guidance.

If we can reach consensus on such a policy I'm sure that in due  
course the RIRs would add pointers to it. It would be helpful if you  
(and others) could explain what it is you want to accomplish, then we  
can see if it's possible to come up with something creative that  
addresses this while avoiding the issues that were mentioned earlier.