[ppml] IPv6 assignment - proposal for change to nrpm

[briand at ca.afilias.info]

> On 10/20/07, briand at ca.afilias.info <briand at ca.afilias.info> wrote:
>> > This is a very bad idea.  The requirement that a "minumum" end-user
>> site
>> > assignment of a /64 is the only thing that will permit many Legacy /24
>> > holders (such as myself) who are single-homed use IPv6 at all.
>>
>> I'm interested in understanding this proposition.
>> Can you explain why you believe /24 Legacy holders would not be able to
>> use, for example, a /120?
>
> Brian,
>
> Given that we could assign a /48 to every individual who has ever
> lived without filling a /14, and given that the IETF has defined
> standards that only work properly when the subnet mask is /64, I'm
> curious why you'd want to buck the IETF on the recommendation against
> assigning prefixes longer than /64?

I'll answer your question in good faith, but ask you *again*, to answer
my basic question:

What, if anything, do you believe forms a *requirement* that a Legacy
/24 cannot use IPv6, unless they receive a /64?

To answer your question(s):
(1) The IETF does not recommend use of specific prefix lengths;
(2) The IETF lists a set of RFCs that must be *supported* by an end node,
    for it to be considered a complete IPv6 implementation
(2.1) However, those RFCs encompass a number of technologies which, while
      supported by an end node, are incompatible, e.g. you need to pick one,
      or do either/or.
(2.2) The IETF does not make recommendations of which node configurations
      are preferable, or which prefix lengths are mandatory
(3) The IETF lists a few methods for constructing Interface Identifiers.
    Currently, those are 64 bits in size.
(3.1) However, the other RFCs only *implicitly* make reference to the size
      of the Interface Identifer, e.g. as N bits and 128-N bits.
(3.2) Specifically, Link Local addresses are constructed as right-aligned
      Interface Identifier, zero-padded, bitwise "OR"-ed with 0xFE80::.
      And, the Link Local address does *not* have a prefix length (!!)

The reason I encourage use of a smaller prefix size than /64, is that the
overall scalability of *all* of the ISPs who have full routing tables,
is dramatically affected by the likelyhood of *any* ISPs getting more than
one PA block for giving out to customers.

And the PA block usage is driven by both the ability to aggregate
internally, and the size of blocks assigned to customers.

With a /32, giving out /48's and doing internal aggregation, a new block
may be needed in as little as 20k assignments - and under current policies,
would be a perfectly acceptable basis for requesting an additional block.

The error is in taking the number of /N blocks that fit in a /M blocks,
and presuming that they can be assigned in a completely efficient manner,
effectively serialized assignments. This is not the case in real world
allocation environments, and particularly not when internal aggregation
is a very important consideration.

(See the IETF draft on the IETF web site, search for "dickson" in the
draft tracker, and read the whole thing, to understand what I'm talking
about, and to see examples of aggregation and allocation techniques.)

So, to summarize:
(1) I'm concurrently asking ARIN to be more forward thinking in their own
allocation policies, and the policies the recommend to their members,
and also working on the IETF to change the standards for IPv6, to better
accommodate the real-world needs as opposed to the "1997 future world need"
that the IETF originally built IPng around (later renamed IPv6);
(2) The IETF does not have allocation policies or recommendation, so there
are none such to buck;
(3) I am not an ISP, nor do I work for one, and have no vested interest
in this other than to educate those who are ISPs or work for them, that
they are headed into a potential IPv6 crib-death scenario, and that given
the perceived need for IPv6 to co-exist with IPv4, to keep the Internet
as a going concern, that such a crib-death would be very, very bad.

Static assignments and DHCPv6 assignments, for prefixes > /64, are not only
possible, but fully compatible with the IETF specifications.

The real question is, if an end-site can implement a long-term plan, using
those two technologies, and based on their long-term needs (10 or 20 year
is entirely reasonable), request a huge IPv6 block, such as a /80, why
would they not give consideration to making a request for a /80?

(Hint: at the current time, the OUI portion of MAC-48 is about 0.1% used.
This means that all the Ethernet devices ever made, number much less than
10^22, or a /90. Even if the number of Ethernet devices increases by 1000,
the will still be able to be numbered at layer 2, with MAC-48, and would
all be able to be assigned IPv6 addresses from within a single /80.)

BTW - I'm trying to avoid getting into one-on-one discussions on technical
aspect of this thread. If anyone sees issues discussed by anyone else,
please read my response to that, rather than re-raise it. I may privately
point you to the other thread, but won't beat this to death more than
once per technical item. :-)

Brian


> Regards,
> Bill Herrin
>
> --
> William D. Herrin                  herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr.                        Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>