ietf
[Top] [All Lists]

Re: IPv6 addresses really are scarce after all

2007-08-29 00:08:12


--On Tuesday, 28 August, 2007 16:43 -0700 Joel Jaeggli
<joelja(_at_)bogus(_dot_)com> wrote:

This is the key point. And as David well knew when he posted
his note, LIRs are not end sites and are treated _very_
differently. A /32 is the default minimum size an LIR gets.
For those not familiar with the terminology, an LIR is what
we usually think of as a ISP or provider, where the
organization provides internet connectivity for a number of
other organizations.

Many large organizations and most if not all isps are in a
position to qualify as IPv6 LIR's.

6.5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an
organization must:

   1. be an LIR;
   2. not be an end site;
   3. plan to provide IPv6 connectivity to organizations to
which it will assign IPv6 address space, by advertising that
connectivity through its single aggregated address allocation;
and
   4. be an existing, known ISP in the ARIN region or have a
plan for making at least 200 /48 assignments to other
organizations within five years.

The traditional meaning of LIP is someone who is in a business
equivalent to that of an ISP and an ISP assigning moderately
long-lived (not single address for a for a single connection)
address pool to others.  E.g., someone providing dial-up access
to unrelated (except by the transfer of money) others may well
be an ISP, but has historically not been considered to be an
LIR.    To say that IBM or Microsoft (to use your example) are
really big organizations with multiple locations are LIRs as a
consequence of the fact of their size (and/or power) turns the
terminology, and concept of an LIP acting as a registry and
making suballocation on its ear.   

The statement above is consistent with that analysis so,
whatever ARIN is doing, they haven't gone into the Humpty Dumpty
business (in which words mean whatever they claim they do at the
moment) yet.

As a data point, ARIN (in the last year) adopted a IPv6 PI
for end sites doing multihoming policy. Such end sites get a
/48.

or larger...

6.5.8.1. Criteria

To qualify for a direct assignment, an organization must:

   1. not be an IPv6 LIR; and

again, consistent.  Note the "not".

   2. qualify for an IPv4 assignment or allocation from ARIN
under the IPv4 policy currently in effect.

In other words, to get IPv6 PI space, I must already qualify for
IPv4 PI space.  That seems reasonable on the basis of history.
But, as IPv4 space gets very tight (as predicted), it could be
construed as a mechanism by which incumbent ISPs and other
organizations who already have large blocks of legacy IPv4 space
keep new entrants, especially any who have business and/or
network models that are be IPv6-only, from playing.   I think
there are technical terms for that sort of strategy.
 
6.5.8.2. Initial assignment size

Organizations that meet the direct assignment criteria are
eligible to receive a direct assignment. The minimum size of
the assignment is /48. Organizations requesting a larger
assignment must provide documentation justifying the need for
additional subnets.

This gets us to /48, not /32.  It also says that, under some
circumstances, an organization can go to ARIN directly for space
rather than an LIR or getting PA space from an ISP.  Having that
allocation size be the same size that (i) IETF considers normal
and (ii) ARIN encourages LIPs to give out to entities who need a
large handful of subnets, rather than one the basis of HD
ratios, seem strange to me given the claims that IPv6
multihoming does not require PI space and separate routing.
Indeed, such a policy seems to me to be more of a threat to
routing table size than encouraging ISPs to give out /48s (that
they will aggregate into their large, LIP, blocks, for routing
purposes) all the time, but that is probably a separate issue.

In addition, again using your example, unless IBM or Microsoft
has deployed IPv6-working and connected hosts on the order of
80% of a /36 (or at least 80% of a /44 or some intermediate
number), they have justified a /32 (if at all) on the basis of
promises and network designed, not actual use.  While their
production (?) IPv6 deployment may have gotten very large when
none of us were looking, that would otherwise be a fairly large
chunk for an initial allocations from a body that was trying to
conserve space.

These assignments shall be made from a distinctly identified
prefix and shall be made with a reservation for growth of at
least a /44. 6.5.8.3. Subsequent assignment size

So, if I have a plan about 16 subnets, I get a /48 from my ISP.
If I can justify that much space on the basis of HD ratio, not
just number of subnets, I can go to ARIN, claim multihoming and
whine, plead, or, if I'm large enough, beat my chest, I can get
a PI /48 with a reservation of the rest of the /44 (or larger)
instead.   Maybe that is ok, except (i) IPv6 is not supposed to
require PI space on the basis of multihoming and (ii) that
criterion has nothing to do with whether one is an LIR.

Additional assignments may be made when the need for
additional subnets is justified. When possible, assignments
will be made from an adjacent address block.

But now we are back to a "subnet count" criterion.   I don't
know what ARIN intends, but a plausible reading of this is that
I have to justify a PI /48 on the basis of HD ratio (and, of
course, already having IPv4 PI space or being able to get it).
Of course, the other possibility is that this really is about
subnets.  I.e., we don't care any more about _host_ density or
efficient use of address space and designing networks to ensure
a maximum number of hosts per subnet.   On that model, all I
need to justify a /32 is a nice drawing or two that explains how
many subnets I need on the basis of physical locations, a
cross-product of authorization domains and so on.   Of course,
for that story to be believed, I also have to hold an
equivalently large block of IPv4 PI space (no non-incumbents
need apply... see above).  But I didn't think that was where we
were headed.

     john


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf