RE: v6 multihoming and route filters

["Azinger, Marla" <marla_azinger@eli.net>]

>>>>>>>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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of Iljitsch van Beijnum
Sent: Wednesday, July 05, 2006 1:28 AM
To: Christian Huitema
Cc: Marc Blanchet; v6ops@ops.ietf.org
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.)