RE: v6 multihoming and route filters

["Sofia, Rute" <rute.sofia@siemens.com>]

I have to say: I go with Christian on this one. I do not see exactly the
point in having the IETF mandating a routing policy. Whatever you
believe you can predict now (e.g., /48 being assigned to end-users) may
require a change in the future and then the filtering rules may in fact
not hold.

Routing recommendations should (and are) provided by LIRs. That should
be enough, right?

Rute Sofia


 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Azinger, Marla
> Sent: Wednesday, July 05, 2006 6:12 PM
> To: Iljitsch van Beijnum; Christian Huitema
> Cc: Marc Blanchet; v6ops@ops.ietf.org
> Subject: RE: v6 multihoming and route filters
> 
> >>>>>>>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.)
> 
> 
>