IPv6 Advertisements

>> I understand the problems but I think there are clear cut cases where
>> /48's make sense- a large scale anycast DNS provider would seem to be a
>> good candidate for a /48 and I would hope it would get routed. Then again
>> that might be the only sensible reason...
>
> Don't give people an excuse to deagg their /32
RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be
any deaggregation in that case.

That's not what I said. If /48 are accepted by * then people with
a /32 or whatever will deagg to /48.

How much and why they deagg will vary but *hand waving argument* it'll
be a lot more pressure on routing table size than people doing PI

You get one shot at fixed prefix size filters, miss and you'll pay
forever. Which is more scarce, /32's or routing table entries.

brandon

Don't give people an excuse to deagg their /32

RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be
any deaggregation in that case.

That's not what I said. If /48 are accepted by * then people with
a /32 or whatever will deagg to /48.

I understand now that you were referring strictly to filter limits- I misinterpreted you original post. My apologies.

Obviously you don't need to accept /48's from anywhere- you can restrict it to the PI pool- then /32's don't deaggregate but networks approved by ARIN or RIPE or whomever still work.

You get one shot at fixed prefix size filters, miss and you'll pay
forever. Which is more scarce, /32's or routing table entries.

If we start giving out /32's to work around filters I'm not sure that solves any problems :slight_smile: And if no one is going to honor a /48 then why bother to give them out?

-Don

You get one shot at fixed prefix size filters, miss and you'll pay
forever. Which is more scarce, /32's or routing table entries.

  your first lema is false.
  and RTE are more scarce.

brandon

  let me ask you two questions:
    ... how many /32's are there?
    ... how many of them will you allow in your routing table?

  and a bonus question:
    ... what are your criteria for rejecting a given /32?

--bill

bmanning@karoshi.com wrote:

You get one shot at fixed prefix size filters, miss and you'll pay
forever. Which is more scarce, /32's or routing table entries.

  your first lema is false.
  and RTE are more scarce.

brandon

  let me ask you two questions:
    ... how many /32's are there?

The same number as there are /32s in ipv4, also the same number as there
are AS numbers which has a certain nice congruency to it...

    ... how many of them will you allow in your routing table?

Hopefully not all of them by tomorrow.

Thus spake "Brandon Butterworth" <brandon@rd.bbc.co.uk>

> Don't give people an excuse to deagg their /32

RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be
any deaggregation in that case.

That's not what I said. If /48 are accepted by * then people with
a /32 or whatever will deagg to /48.

The general rule, for both v4 and v6, is that people should filter on whatever the minimum allocation/assignment size for each RIR block. It's also been suggested that you accept a few more bits for routes with a short AS_PATH length to help with TE, but that's optional.

Someone recently posted a link (either on PPML or here -- I can't find it now) that showed ARIN's minima for the various v4 and v6 blocks. The v4 ones were all over the map, but there are relatively few v6 blocks and all of them are /32 except for one that's /48.

The upside is that in the block you're expected to accept /48s, nobody will have a /32. The downside is that anyone who gets a larger-than-minimum sized allocation/assignment can deaggregate down to that level.

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

The upside is that in the block you're expected to accept /48s, nobody will have a /32. The downside is that anyone who gets a larger-than-minimum sized allocation/assignment can deaggregate down to that level.

I don't think ARIN is planning on giving out more less a /48 but more than a /32- at least that was the impression I got. End sites get a /48- ISP's get a /32 or larger- and that's it (I could certainly be wrong). As such, deaggragation in the /48 block should not be an issue because no one will have more than a /48 in the first place.

-Don

Yes, you can get a prefix between /32 and /48 if you can justify it. That is certainly
in line with the policy which resulted from proposal 2005-1.

Owen

Thus spake "Donald Stahl" <don@calis.blacksun.org>

The upside is that in the block you're expected to accept /48s,
nobody will have a /32. The downside is that anyone who gets
a larger-than-minimum sized allocation/assignment can
deaggregate down to that level.

I don't think ARIN is planning on giving out more less a /48 but
more than a /32- at least that was the impression I got. End sites
get a /48- ISP's get a /32 or larger- and that's it (I could certainly
be wrong). As such, deaggragation in the /48 block should not
be an issue because no one will have more than a /48 in the
first place.

Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that.

So, it's entirely possible someone could get a /40 and deaggregate that into 256 routes if they wanted to. Given the entire v6 routing table is around 700 routes today, it's obviously not a problem yet :slight_smile:

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

I don't think ARIN is planning on giving out more less a /48 but more than a /32- at least that was the impression I got. End sites get a /48- ISP's get a /32 or larger- and that's it (I could certainly be wrong). As such, deaggragation in the /48 block should not be an issue because no one will have more than a /48 in the first place.

Yes, you can get a prefix between /32 and /48 if you can justify it. That is certainly
in line with the policy which resulted from proposal 2005-1.

You are of course correct- I misread "The minimum assignment size is /48" in terms of prefix length (ie minimum of /48- could be /56, etc.) which is not what was meant. The very next sentence should have clarified that for me but I probably skipped over it. mea culpa.

I'm looking forward to seeing a realistic justification from an end user for more than a /48 :slight_smile:

As an aside- what is the address block for PI end user assignments from ARIN? (I can't seem to find it and 2005-1 only mentions a "distinctly identified prefix" without any mention of what that would be).

The Microallocation blocks are:

Internal Infrastructure: 2001:0506::/31
Exchange Points: 2001:0504::/31
Critical Infrastructure: 2001:0500::/30

(all of which are /48's so far).

But I see no mention of end-user assignments (unless they fall into one of the above categories- though I don't see how).

-Don

Current policy allows for greater-than-/48 PI assignments if the org can justify it. However, since we haven't told staff (via policy) what that justification should look like, they are currently approving all requests and several orgs have taken advantage of that.

I can't imagine what an end-user could come up with to justify more than a /48 but what do I know. And if ARIN's primary goal is to prevent de-aggregation then shouldn't there be another fixed allocation size (/40) and block to prevent this?

So, it's entirely possible someone could get a /40 and deaggregate that into 256 routes if they wanted to. Given the entire v6 routing table is around 700 routes today, it's obviously not a problem yet :slight_smile:

Obviously that's short sighted :slight_smile: As for the deaggregation- anyone deaggregating a /40 into 256 routes should have there AS permanently bloackholed :slight_smile:

-Don

Donald Stahl wrote:

As for the deaggregation- anyone deaggregating a /40 into 256 routes
should have there AS permanently blackholed :slight_smile:

I think you omitted an "S" there, Donald :slight_smile:

Jeff

Thus spake "Donald Stahl" <don@calis.blacksun.org>

Current policy allows for greater-than-/48 PI assignments if the
org can justify it. However, since we haven't told staff (via
policy) what that justification should look like, they are currently
approving all requests and several orgs have taken advantage
of that.

I can't imagine what an end-user could come up with to justify
more than a /48 but what do I know.

First of all, there's disagreement about the definition of "site", and some folks hold the opinion that means physical location. Thus, if you have 100 sites, those folks would claim you have justified 100 /48s (or one /41). Other folks, like me, disagree with that, but there are orgs out there that have tens of thousands of locations with a need for multiple subnets per location, and that could justify more than a /48 as well via pure subnet counts.

And if ARIN's primary goal is to prevent de-aggregation then
shouldn't there be another fixed allocation size (/40) and block
to prevent this?

ARIN's goal in v6 is to try to issue blocks so that aggregation is _possible_, by reserving a larger block to allow growth, but ARIN can't prevent intentional (or accidental) deaggregation, and there's too many folks who want to deaggregate for TE purposes to pass a policy officially condemning it.

So, it's entirely possible someone could get a /40 and
deaggregate that into 256 routes if they wanted to. Given
the entire v6 routing table is around 700 routes today, it's
obviously not a problem yet :slight_smile:

Obviously that's short sighted :slight_smile: As for the deaggregation-
anyone deaggregating a /40 into 256 routes should have
there AS permanently bloackholed :slight_smile:

I'd agree in principle, but all it takes is a brief look at the CIDR report and you'll see that nobody does anything in response to far more flagrant examples in v4. If everyone aggregated properly, we could drop over a third of the current v4 table. This makes me extremely suspicious of ISPs that continually whine about routing table bloat whenever loosening policies for small orgs is discussed.

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

The general rule, for both v4 and v6, is that people should filter on whatever the minimum allocation/assignment size for each RIR block.

Did someone take the trouble to tell RIPE that?

193/8 /29
194/7 /29

That allows for 6291456 prefixes when fully deaggregated.

Someone recently posted a link (either on PPML or here -- I can't find it now) that showed ARIN's minima for the various v4 and v6 blocks.

[ALLOCSIZE-APNIC] APNIC, "Allocation sizes within APNIC IPv4 address
                   ranges", http://www.apnic.net/db/min-alloc.html

[ALLOCSIZE-LACNIC] LACNIC, "LACNIC - Registration Services",
                    http://lacnic.net/en/registro/index.html

[ALLOCSIZE-RIPE] L. Vegoda, "RIPE-380 Address Space Managed by the RIPE
                  NCC", June 2006,

[ARIN-MICRO] ARIN, "ARIN Micro-allocations",
              http://www.arin.net/reference/micro_allocations.html

Thus spake "Stephen Sprunk" <stephen@sprunk.org>

Someone recently posted a link (either on PPML or here -- I can't find it now) that showed ARIN's minima for the various v4 and v6 blocks. The v4 ones were all over the map, but there are relatively few v6 blocks and all of them are /32 except for one that's /48.

This is the page I was thinking of:

http://www.arin.net/reference/ip_blocks.html

The v6 list doesn't show explicit minima like the v4 list, but it's /32 for non-micro allocations (the block for which, unfortunately, isn't noted on this page) and /48 for direct assignments under current policy.

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

First of all, there's disagreement about the definition of "site", and some folks hold the opinion that means physical location. Thus, if you have 100 sites, those folks would claim you have justified 100 /48s (or one /41). Other folks, like me, disagree with that, but there are orgs out there that have tens of thousands of locations with a need for multiple subnets per location, and that could justify more than a /48 as well via pure subnet counts.

Companies with tens of thousands of sites, each needing multiple subnets is not the norm for end user allocations. And again- would the administrative overhead of a new /40 netblock really outweigh the benefits to our routing tables? I'm asking not stating...

ARIN's goal in v6 is to try to issue blocks so that aggregation is _possible_, by reserving a larger block to allow growth, but ARIN can't prevent intentional (or accidental) deaggregation,

But ARIN has the power to give the community the tools it needs to force aggregation (if the community decides they want)- even if it isn't ARIN's own policy.

and there's too many folks who want to deaggregate for TE purposes to pass a policy officially condemning it.

I understand limited deaggregation for TE purposes- but that doesn't mean you have to let people go nuts. 1 or two bits is one thing- 8 (or more) is another animal all together.

I'd agree in principle, but all it takes is a brief look at the CIDR report and you'll see that nobody does anything in response to far more flagrant examples in v4.

So because v4 is screwed up we should let v6 get just as bad?

The time to fix these sorts of issues is now- before it's really live, rather than later.

-Don

Stephen Sprunk wrote:

Thus spake "Donald Stahl" <don@calis.blacksun.org>

Current policy allows for greater-than-/48 PI assignments if the
org can justify it. However, since we haven't told staff (via
policy) what that justification should look like, they are currently
approving all requests and several orgs have taken advantage
of that.

I can't imagine what an end-user could come up with to justify
more than a /48 but what do I know.

First of all, there's disagreement about the definition of "site",

The general definition of a site that I find appropriate is and works
pretty well as a rule of thumb:

"A site is defined by it having a single administrative domain".

As such, if you have for example an NREN, most likely every University
will have their own Networking Department, with their own
administrators of that network. As such, every university is a site.
When the University is very large, it will have multiple
administrative portions, eg generally Computer Science will have their
own folks managing the network.

When you have a large company, the company is also split over several
administrative sites, in some cases you might have a single
administrative group covering several sites though, this allows you to
provide them with a single /48 as they are one group they will know
how to properly divide that address space up.

It comes sort of close to an AS actually, except that an AS tends to
cover a lot of sites.

some folks hold the opinion that means physical location. Thus, if you
have 100 sites, those folks would claim you have justified 100 /48s (or
one /41). Other folks, like me, disagree with that, but there are orgs
out there that have tens of thousands of locations with a need for
multiple subnets per location, and that could justify more than a /48 as
well via pure subnet counts.

If you have 40k sites, then a /32 is a perfect fit for you. There are
not too many organizations that come close to that though, making
/32's excellent for most organizations, except the very small ones.
These can request a /48, or something upto a /40 for that purpose.

Greets,
Jeroen

Works great, until you realize that for traffic engineering purposes, you
really want to announce your Los Angeles site at an exchange near there,
and your London site to be announced near there, and you end up wondering
whether deaggregating the /48, or getting a second/third /48 would be wiser.. :wink:

Yes, that is indeed one of the many problems that come associated with
getting a huge /32. You are supposed to announce that at in one
aggregated chunk...

At the moment you end up announcing chunks of the /48 to the local
area and backhauling traffic from one site to another. The option for
getting a separate /48 per site is then very tempting I guess. Unless
you have a 10k or so of those sites...

Firewall-wise having one big chunk is of course very interesting as
you only need 1 ACL. Then again, do you trust everybody in your
company? :slight_smile: I guess that a different way of authentication, eg using
authenticated packets (IPSEC AH) will become more and more common.
One part missing there is a "Token" which can be added though, eg you
have a local Authority which says "I allow X to send packet from Y to
Z", take that token and attach it to packets. Firewalls trust the
Authority and thus allow those packets through. Accidentally this is
similar to something that came up in the DTN meeting last week.

This is something that needs to be solved with a magic new routing
mechanism though, like a lot of other things.

Greets,
Jeroen

Thus spake "Jeroen Massar" <jeroen@unfix.org>

Stephen Sprunk wrote:

First of all, there's disagreement about the definition of "site",

The general definition of a site that I find appropriate is and
works pretty well as a rule of thumb:

"A site is defined by it having a single administrative domain".

That's a good rule of thumb; I'm curious how close it is to what ARIN staff uses when evaluating requests, though. Or if staff let the requestor define "site" themselves since policy doesn't.

As such, if you have for example an NREN, most likely every
University will have their own Networking Department, with their
own administrators of that network. As such, every university is
a site.

That's reasonable, if for no other reason than the number of universities is manageable and there's no doubt they're independently managed -- follow the money. However, I'd argue that NREN is an LIR and the universities are their customers.

When the University is very large, it will have multiple
administrative portions, eg generally Computer Science will
have their own folks managing the network.

That can be handled by subdividing the /48 that goes to the U.

When you have a large company, the company is also split
over several administrative sites, in some cases you might
have a single administrative group covering several sites
though, this allows you to provide them with a single /48 as
they are one group they will know how to properly divide that
address space up.

In my experience, there tends to be one corporate IT group that handles stuff like connectivity to other orgs, and several subordinate IT groups that manage their part of the network. That can be handled with chopping up their /48.

In the case of the rare (typically multinational) org where the groups run independent networks that talk BGP to each other and/or have their own uplinks, it'd be fair for ARIN to consider each group a separate site or even org if requested. Ditto if a single org had multiple separate networks but only one IT group (e.g. hosters).

It comes sort of close to an AS actually, except that an AS
tends to cover a lot of sites.

An end-user AS tends to cover a lot of locations. By definition, it describes an area with a single coherent routing policy and administrator.

An ISP AS may cover a lot of sites because leaf sites are part of their upstream's AS as far as routing is concerned.

If you have 40k sites, then a /32 is a perfect fit for you. There
are not too many organizations that come close to that though,
making /32's excellent for most organizations, except the very
small ones. These can request a /48, or something upto a /40
for that purpose.

Let's take our canonical example of McDonald's. Does each store (let's assume they're all company-owned, not franchisees, for a moment) really count as a "site"? It's definitely a location, but if there's a single IT group that manages all 100k or so of them, I'd argue they're all one "site", certainly one org, and not an LIR. Give each store a /60 (to make rDNS easy and allow for growth), and McD's as a whole would get a /40 or so (to allow for internal aggregation).

However, as I noted, some folks would consider McD's an LIR and want to give them a /30 or shorter. I think that's wrong, but policy doesn't clearly say either way. Looking at WHOIS doesn't help much, since many obvious end-user orgs like Cisco got LIR allocations back when there was no end-user PIv6 policy; who knows what they'd be told today if they applied with the same rationale. (Though presumably they wouldn't try since assignments are far cheaper to renew)

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

> When you have a large company, the company is also split
over several
> administrative sites, in some cases you might have a single
> administrative group covering several sites though, this
allows you to
> provide them with a single /48 as they are one group they will know
> how to properly divide that address space up.

Works great, until you realize that for traffic engineering
purposes, you really want to announce your Los Angeles site
at an exchange near there, and your London site to be
announced near there, and you end up wondering whether
deaggregating the /48, or getting a second/third /48 would be
wiser.. :wink:

I believe that a separate /48 per site is better regardless of whether
or not the company has contracted with a single ISP for all sites, or
not. As far as I am concerned if there is a separate access circuit,
then it is a site and it deserves its own /48 assignment/allocation.

--Michael Dillon