ietf
[Top] [All Lists]

IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

2007-08-29 08:07:25
Note, while I think it's useful to have an educational discussion
about IPv6 addressing policy on the IETF list, it's also a tad
frustrating how selective/partial context quoting leads the discussion
veering off in all kinds of random directions...

I'd encourage folk to read the entire IPv6 policy to get a more
complete picture. It's not that long. ARIN's is at:
http://www.arin.net/policy/nrpm.html#ipv6.

John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:

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.

That claim/myth seems remarkably difficult to quash. Let me say it
clearly: IPv6 has no magic multi-homing solution, and the multihoming
approachs that IPv6 offers are essentially equivalent to those
available in IPv4.

Note that in the RIR community, this has been obvious for some time,
and is one of the reasons why the policies being developed there have
a lot of similarities to IPv4 policies (but they still do have
important differences).

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.

Yes, and the debate was quite contentious and played out over a number
of years. But eventually the "be very scared" arguments were drowned
out by the "IPv4 hasn't collapsed yet, and we need parity with IPv4,
when it comes to PI addressing".

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.

Sorry, the 80% utilization metric is specific to IPv4. IPv6 doesn't
use this same utilization formula to measure the actual "utilization"
of a chunk of address space, it uses the HD-ratio metric.

And, since this is also very different in IPv6, let me point out that
what is counted is subnets, not hosts. Quoting from the ARIN document:

    6.2.7. Utilization
    
    In IPv6, "utilization" is only measured in terms of the bits to the
    left of the /56 boundary. In other words, utilization refers to the
    assignment of /56s to end sites, and not the number of addresses
    assigned within individual /56s at those end sites.
    
    Throughout this document, the term utilization refers to the
    allocation of /56s to end sites, and not the number of addresses
    assigned within individual /56s within those end sites.

And, for those of you worried about end users being given a /64 (or
worse), from a registry perspective, it is 100% acceptable to give
every end site a /56. That is what the above wording means, and that
is what the RIRs expect LIRs to do. If LIRs/ISPs choose to give end
sites less space than that, there really is no significant benefit to
them doing so. Indeed, I would expect that if an ISP stingily gave out
only /64s, it would find that there are other ISPs that are more than
happy to offer /56s. Thus there would be some marketting disadvantages
to being stingy and they have some discincentive to being overly
stingy.

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.

The RIRs are not trying to "conserve" in the same sense as for
IPv4. The balance has clearly shifted to being less conservative in
terms of ultilization and also trying harder to avoid fragmentation of
the address space resulting from growth.

Quoting again from the ARIN document:

    6.3.4. Aggregation
    
    Wherever possible, address space should be distributed in a
    hierarchical manner, according to the topology of network
    infrastructure. This is necessary to permit the aggregation of
    routing information by ISPs, and to limit the expansion of
    Internet routing tables.
    
    This goal is particularly important in IPv6 addressing, where the
    size of the total address pool creates significant implications
    for both internal and external routing.
    
    IPv6 address policies should seek to avoid fragmentation of
    address ranges.
    
    Further, RIRs should apply practices that maximize the potential
    for subsequent allocations to be made contiguous with past
    allocations currently held. However, there can be no guarantee of
    contiguous allocation.
    
    6.3.5. Conservation
    
    Although IPv6 provides an extremely large pool of address space,
    address policies should avoid unnecessarily wasteful
    practices. Requests for address space should be supported by
    appropriate documentation and stockpiling of unused addresses
    should be avoided.
    
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.

There is that myth again. :-(

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.

Your mixing things a bit here. The first part of the text refers to
the PI for end sites policy. The /32 applies to LIRs, a different
category of address assignment.

Thomas

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