[ppml] IPv6 assignment - proposal for change to nrpm

[Azinger, Marla]

Just a note on the RFC debate.

3177 is a recommendation from 2001 and not a standar of any kind.  It says so in the first paragraph.  Related to this,I am finding that there are people who are actually working with creating their IPv6 networks and they are finding this recommendation to be far more wasteful then originally thought.  So to some this recommendation is outdated and not a good one if you choose to learn from history. *I know everyone will not agree with my last statement but I just want to point out that it is an opinion that is growing larger.

Cheers~
Marla

 

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Stephen Sprunk
Sent: Sunday, October 21, 2007 8:50 PM
To: briand at ca.afilias.info
Cc: ARIN PPML
Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm


Thus spake <briand at ca.afilias.info>
>> 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?

Because, according to the IETF, a single subnet should be a /64.  Even folks 
who are using DHCPv6 are assigning /64s, from what I've seen.

> To answer your question(s):
> (1) The IETF does not recommend use of specific prefix lengths;

Actually, it did.  Please see RFC 3177.

> (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 (!!)

RFC 4291 definitely implies a /64 for LLAs; the only example given has a 
64-bit IID.

> 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.

First of all, the vast majority (numerically) of LIRs will never need to 
make more assignments than that.  Those that do will likely be using /56 
assignments for most customers, which were specifically adopted for such 
LIRs that wanted them.

Second, /32 is only the _minimum_ size allocation.  LIRs can request more 
space, and at least two* have according to ARIN's WHOIS.  In other regions, 
where IPv6 has been rolled out more aggressively, one can see allocations as 
short as /19.  That's a heck of a lot of /48 assignments, even with several 
levels of internal aggregation.

(* Sprint with a /29 and VZB with a /27, both out of what appear to be /21s 
reserved for future growth.  /32s appear to get /29 reservations.)

> 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.

Hardly; the whole point of using the HD Ratio is that it allows for 
aggregation causing inefficient utilization.  The more bits you need for 
actual subnets, the more bits you get to burn on internal hierarchy.

> 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?

That's a miniscule block by current standards, not "huge".  You're focusing 
almost exclusively on the lower-order bits and trying to justify minimizing 
their use, but you haven't given any decent reason why we're short on 
higher-order bits.  128 bits is a _lot_.  That number was chosen (vs. 64) so 
that we'd have so many we wouldn't need to worry about wasting them, even 
when using EUI-64s for the host part.  64 bits for the network prefix is far 
more than we can figure out how to assign, much less route...

If we did, for example, stuff every end site into a /80, we still couldn't 
route more than a /60 of space today in the DFZ.  IMHO, that says you're 
worrying about the wrong problem.  We can barely manage routing 20 bits of 
prefixes today, perhaps 24 bits within a few years.  Today's /32s  for LIRs 
and /48s for end sites are already ridiculously long because we can't 
possibly route the number of prefixes possible with those sizes; there is no 
point, IMHO, in making allocations/assignments longer than that.  And, if 
those are the top-level sizes, there is no rational need for anything longer 
than /64s for individual subnets, except perhaps for PTP links (where /127s 
do sort of make sense).

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.