filtering /48 is going to be necessary

Mailman List Mirror (Read Only)
1

I had a bit of off-list discussion about this topic, and I was not
going to bring it up today on-list, but since the other point of view
is already there, I may as well.

Unless you are going to pay the bill for my clients to upgrade their
3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
to do two things before IPv6 up-take is really broad:

1) absolutely must drop /48 de-aggregates from ISP blocks
2) absolutely must make RIR policy so orgs can get /48s for
anycasting, and whatever other purposes

If we fail to adjust RIR policy to account for the huge amount of
accidental de-aggregation that can (and will) happen with IPv6, we
will eventually have to do #1 anyway, but a bunch of networks will
have to renumber in order take advantage of #2 down the road.

The way we are headed right now, it is likely that the IPv6 address
space being issued today will look like "the swamp" in a few short
years, and we will regret repeating this obvious mistake.

We had this discussion on the list exactly a year ago. At that time,
the average IPv6 origin ASN was announcing 1.43 routes. That figure
today is 1.57 routes per origin ASN.

2

if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6.

I had a bit of off-list discussion about this topic, and I was not
going to bring it up today on-list, but since the other point of view
is already there, I may as well.

Unless you are going to pay the bill for my clients to upgrade their
3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
to do two things before IPv6 up-take is really broad:

1) absolutely must drop /48 de-aggregates from ISP blocks

See the strict filter at:
http://www.space.net/~gert/RIPE/ipv6-filters.html

which has been proposed for quite a long time already.

Also note the existence of this awesome thing called RPSL.

See also this great presentation by ras:

and the very recent column by Geoff Huston:
http://www.potaroo.net/ispcol/2012-03/leaks.html

2) absolutely must make RIR policy so orgs can get /48s for
anycasting, and whatever other purposes

One can already receive those easily, generally as a /48.

Also, quite a few organizations are requesting disjunct /32's per
country or at least a /32 per region....

Greets,
Jeroen

3

Hi Jeff,

We could use smarter prefix filtering than that. Which was proposed to
ARIN a couple years ago. And failed.

http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html

Regards,
Bill Herrin

4

Hello Jeff,

if you know anyone who is filtering /48 , you can start telling them
to STOP doing so as a good citizen of internet6.

I had a bit of off-list discussion about this topic, and I was not
going to bring it up today on-list, but since the other point of view
is already there, I may as well.

Unless you are going to pay the bill for my clients to upgrade their
3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
to do two things before IPv6 up-take is really broad:

1) absolutely must drop /48 de-aggregates from ISP blocks
2) absolutely must make RIR policy so orgs can get /48s for
anycasting, and whatever other purposes

I used to be (or still am) on the same page as you are. I was dropping
everything smaller than a /36 from PA ranges at the edge.

I recently had to relax this filter, because Cloudflare seems to insist
on throwing tons of /48s from their 2400:cb00::/32 into the air without
an aggregate. And guess what the popular cloud reverse proxy for IPv6
webpages is these days ... cloudflare.

Yes, it sucks, yes, I wrote them, but no answer and no change.

Best Regards,
Bernhard

5

I think ARIN issues /48s for Provider independent space as the minimum
allocation size, so I'm guessing we shouldn't filter below that. At least,
that's what's in their current policies.

6

I think ARIN issues /48s for Provider independent space as the
minimum allocation size, so I'm guessing we shouldn't filter below
that. At least, that's what's in their current policies.

Note that I explicitly wrote:

I used to be (or still am) on the same page as you are. I was
dropping everything smaller than a /36 from PA ranges at the edge.

                                          ^^^^^^^

Of course I'm accepting /48 from PI range (in ARIN world 2001:500::/30 2001:504::/30 and 2620::/23), anything else would be quite brain-dead and stupid.

Bernhard

7

if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6.

I had a bit of off-list discussion about this topic, and I was not
going to bring it up today on-list, but since the other point of view
is already there, I may as well.

Unless you are going to pay the bill for my clients to upgrade their
3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
to do two things before IPv6 up-take is really broad:

1) absolutely must drop /48 de-aggregates from ISP blocks
2) absolutely must make RIR policy so orgs can get /48s for
anycasting, and whatever other purposes

Item 1 will be interesting.
Item 2 is already done in ARIN and I think RIPE and APNIC.
I'm not sure about AfriNIC or LACNIC.

If we fail to adjust RIR policy to account for the huge amount of
accidental de-aggregation that can (and will) happen with IPv6, we
will eventually have to do #1 anyway, but a bunch of networks will
have to renumber in order take advantage of #2 down the road.

Can you point to specific RIR policies that you believe need adjustment?
I'm willing to help (and somewhat adept at doing so), but I'm not seeing
the problem you are reporting, so, I need more data.

The way we are headed right now, it is likely that the IPv6 address
space being issued today will look like "the swamp" in a few short
years, and we will regret repeating this obvious mistake.

I don't think so, actually. First, I don't think the swamp was a mistake so much
as a temporary problem with resource limitation on routers.

The problem in today's routing table is NOT the "swamp". (Where swamp is
defined as the large number of /24s issued to organizations in a non-
aggregable manner often as direct assignments from the InterNIC before
CIDR and provider-assigned addressing existed).

The total scope of the swamp is limited to about 65,000 prefixes.

All of the growth beyond about 65,000 prefixes is, instead, attributable to
a number of other factors, not the least of which are disaggregation for
convenience (which could be an issue in IPv6), disaggregation due to
ignorance (which will likely be an issue in IPv6), de-aggregation due
to differences in routing policy and/or for traffic management strategies
(which will also happen in IPv6), general growth of the internet (which
will also happen in IPv6, but, at a lower prefix-growth rate), and finally,
one of the biggest causes... slow start, growth constrained RIR policies
handing out incremental (often 1 year worth or less) growth in address
blocks due to scarcity (which should not be a problem in IPv6).

In the ARIN region I think we have pretty well prevented this last issue
with current policy. I tried to propose similar policy in the APNIC region,
but it was not well accepted there. The folks in Asia seem t want to cling
to their scarcity mentality in IPv6 for the time being. I believe RIPE is
issuing reasonably generous IPv6 allocations/assignments. I don't
know enough about the goings on in AfriNIC or LACNIC to comment
with any certainty.

We had this discussion on the list exactly a year ago. At that time,
the average IPv6 origin ASN was announcing 1.43 routes. That figure
today is 1.57 routes per origin ASN.

That represents a 10% growth in prefix/asn for IPv6.

Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While
I would agree that this is a trend that merits watching, I think
we're probably OK for quite some time. The higher growth rate in
IPv6 can be largely attributed to the fact that IPv6 is still in its
infancy and we probably haven't seen much IPv6 traffic engineering
route manipulation yet. I don't think IPv6 is at all likely even with
current policies and trends to reach 9:1. I expect it will most likely
settle in somewhere around 2.5:1.

Owen

8

Let us not forget that there is also the issue of PA /48s being advertised (quasi-legitimately) for some end-user organizations that are multi-homed but choose not to get PI space. It is not uncommon to obtain a PA /48 from provider A and also advertise it from Provider B.

Owen

9

Owen wrote:

[...]

In the ARIN region I think we have pretty well prevented this last issue
with current policy. I tried to propose similar policy in the APNIC region,
but it was not well accepted there. The folks in Asia seem t want to cling
to their scarcity mentality in IPv6 for the time being. I believe RIPE is
issuing reasonably generous IPv6 allocations/assignments. I don't
know enough about the goings on in AfriNIC or LACNIC to comment
with any certainty.

You can see the prefix distribution in charts that are updated daily on our stats web site:

http://stats.research.icann.org/

HTH,

Leo

10

Hi,

Let us not forget that there is also the issue of PA /48s being
advertised (quasi-legitimately) for some end-user organizations that
are multi-homed but choose not to get PI space. It is not uncommon to
obtain a PA /48 from provider A and also advertise it from Provider
B.

While I agree it's not uncommon, I'm not a big fan of this setup. Also, provider A should still have his aggregate announced, which would allow strictly filtering ISPs to reach the destination anyway.

Announcing /48s from a PA block without the covering aggregate calls for trouble.

Bernhard

11

Hi,

Let us not forget that there is also the issue of PA /48s being
advertised (quasi-legitimately) for some end-user organizations that
are multi-homed but choose not to get PI space. It is not uncommon to
obtain a PA /48 from provider A and also advertise it from Provider
B.

While I agree it's not uncommon, I'm not a big fan of this setup. Also, provider A should still have his aggregate announced, which would allow strictly filtering ISPs to reach the destination anyway.

I'm not a big fan, either, but, I think that the concept of "be conservative in what you announce and liberal in what you accept" has to apply in this case. Since it is a common (quasi-)legitimate practice, arbitrarily filtering it is ill-advised IMHO.

The statement about the covering aggregate assumes that there are no failures in the union of {site, loop, provider A}.

In the event that there is such a failure, the aggregate may not help and may even be harmful.

Since one of the key purposes of this kind of multihoming is to provide coverage in the event of such a failure, filtration of the more-specific seems to defeat the purpose.

Announcing /48s from a PA block without the covering aggregate calls for trouble.

No question. However, the covering aggregate alone is also insufficient.

Owen

12

Let us not forget that there is also the issue of PA /48s being advertised (quasi-legitimately) for some end-user organizations that are multi-homed but choose not to get PI space. It is not uncommon to obtain a PA /48 from provider A and also advertise it from Provider B.

What should happen is this "quasi-legitimate" method of
multi-homing should just be declared illegitimate for IPv6, to
facilitate stricter filtering. Instead, what should happen is the
multi-homing should be required to fit into one of 3 scenarios, so
any announcement with an IPv6 prefix length other than the
RIR-allocated/assigned PA or PI block size can be treated as TE and
summarily discarded or prioritizes when table resources are scarce.

Scenario (1) The end user org obtains PI address space from a RIR,
and originates their assigned prefix. The end user org originates
their RIR assigned exact prefix and announces to their upstreams, who
filter and accept from the end user only routes containing a NLRI of
their exact prefix, with the prefix length used by the RIR for the PI
blocks from which their assignment(s) had been made.

(2) Same as (1) but The RIR provides some expedited process for the
ISP to obtain and transfer PI space and AS numbers for the purpose of
their customers' multihoming - in one step, so the end user does not
have to figure out the RIR application process -- E.g. some RIR
process provides the ISP an option to create PI blocks on demand in
addition to their PA block; the ISP will not know in advance what AS
number or PI block will be allocated, the ISP must follow the RIR
rules for the assignment of PI blocks, and educate their user as
needed, obtain a signed RSA with the End user, obtain written proof
the user has two ISPs, has provided a network design that includes
multihoming, and a written sound justification for the multi-homing
or the meeting of a criteria requiring multihoming, provide the End
User's billing contact info to the RIR, the ISP having pre-payed
registration fees to the RIR --- should the end user stop using the
ISP that created the block, responsibility for the PI block and AS
numbers reverts to the end user org.

(3) The end user org who is multi-homed picks a 3rd party
organization to assign to the end user from their PA block. The 3rd
party org's overall PA block is multihomed with diverse connectivity,
and the end user inherits the multihoming of the 3rd party's PA
block.

  The 3rd party AS is the sole AS that originates the prefix in the
form of the entire PA block into the DFZ and then routes the
individually assigned end-user block to the End user through private
arrangement or peering with the End user orgs' upstreams,

(IOW: the multi-homed users block does not appear as a globally
visible more-specific/deaggregate)

(4) Any of the other methods of achieving multi-homing, such as
originating an NLRI with a longer prefix than the RIR delegation,
should be rejected by filters.

13

Hi,

What should happen is this "quasi-legitimate" method of
multi-homing should just be declared illegitimate for IPv6, to
facilitate stricter filtering. Instead, what should happen is the
multi-homing should be required to fit into one of 3 scenarios, so
any announcement with an IPv6 prefix length other than the
RIR-allocated/assigned PA or PI block size can be treated as TE and
summarily discarded or prioritizes when table resources are scarce.

Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). Deaggregating to /48's is not a good idea, but giving an LIR a few bits (something like 3 or 4) to deaggregate makes sense.

- Sander

14

It does make sense to give the LIR a few bits.
Note though I say what "should" happen.

What will happen in actual fact, is probably going to be identical to IPv4.
End users will go to other ISPs and demand they carry their individual /64s;
resulting market pressure is more powerful than efficient design.

15

If the LIRs cannot get separate allocations from the RIR (and separate
ASNs) for this usage, something is wrong.

We want to make things as simple and efficient as possible, but no
simpler or more efficient, because the curves go back up again at that
point, and we all suffer.

-george

16

Hi,

Sander wrote:

Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network).

If they have two different routing policies and need two different allocations, why not just have two different LIRs? It makes things a lot easier than spending untold weeks or time trying to work out which corner cases should be supported by policy and which should not. No?

Leo

17

Owen said:

I'm not a big fan, either, but, I think that the concept of "be
conservative in what you announce and liberal in what you accept" has
to apply in this case. Since it is a common (quasi-)legitimate
practice, arbitrarily filtering it is ill-advised IMHO.

While I agree in principle, 16 bits of disaggregation has the potential for a lot of mayhem and 32 bits (accepting /64 from PA) would be catastrophic. This would seem to be a case where upstream providers can assist the end user in obtaining their own PI space if they wish to multihome. It would be in the provider's interest as it would reduce the number of potential complaints from customers concerning multihoming problems.

I filter /32 from PA space and am currently filtering one route but since the aggregate it is from has the same next hop and since I don't see the route from anyone else, I'm not worried about it.

18

Deaggregating to /48's is not a good idea, but giving an LIR a few bits
(something like 3 or 4) to deaggregate makes sense.

- Sander

+1

I wouldn't have a problem with a few bits of disaggregation. That seems reasonable for a network that might be subject to partitioning or doesn't have a fully meshed internal net.

19

This varies from RIR to RIR.

In the ARIN region, you can get assignments or allocations for Multiple Discreet Networks, but, ARIN will often register them as an aggregate in the registration database, so...

In the RIPE region (which is where I believe Sander is), only aggregates are available to the best of my knowledge.

Owen

20

This may depend on where you are. Being two LIRs in the ARIN region requires setting up two complete legal entities which is a lot of overhead to carry for just that purpose.

Owen