Subject: RE: v6 multihoming and route filters

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 5 Jul 2006 08:45:15 -0700

Correct the IETF isn't the steward of address allocation.  And that is not what we are attempting to do with writing a Best Practice/Recommended Routing Procedure.  However, IETF is the steward of good routing principles.  If IETF sets a good set of principles on routing then Policy in RIR's can and should adjust policy allocation to reflect the suggested good routing principles.

Marla Azinger
Frontier Communications

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Pekka Savola
Sent: Tuesday, July 04, 2006 9:56 PM
To: Marc Blanchet
Cc: Christian Huitema; Iljitsch van Beijnum; [email-masked]
Subject: Re: v6 multihoming and route filters

On Tue, 4 Jul 2006, Marc Blanchet wrote:
>> We should really think twice before asking the IETF to publish a 
>> 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.

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.

-- 
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: "Sofia, Rute" <[email-masked]>
Date: Wed, 5 Jul 2006 18:53:20 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Azinger, Marla
> Sent: Wednesday, July 05, 2006 6:12 PM
> To: Iljitsch van Beijnum; Christian Huitema
> Cc: Marc Blanchet; [email-masked]
> 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
> 
> Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, July 05, 2006 1:28 AM
> To: Christian Huitema
> Cc: Marc Blanchet; [email-masked]
> 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?
> 
> 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.)
> 
> 
>