[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: v6 multihoming and route filters
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.)
>
>
>