[ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call

[Owen DeLong]

> I have to admint that I'm very puzzled by the ongoing effort to keep
> masks bounded by "interesting" numbers of bits. 
> 
> While the vast majority of home users will be fine with a /64, how many
> of the remainder really will ever need a /56?  I suspect that the
> majority not sufficiently serviced by a /64 would be fine with a /63 or
> /62.  Why assign all of that extra space?  It seems to me that you can
> fit a lot of /62s into a single /56.  (Am I just missing something
> obvious here?)
> 
Yes... short answer: ip6.arpa.

Long answer: v6 has enough space that even at the /48 assignment boundary,
we're a long way off from an addressing crisis.  However, allowing a /56
boundary for small business and residential customers could stave that
crisis off, essentially indefinitely.

Reverse DNS assignments for small networks in the V4 world are a kludge.
Let's not repeat that in v6.  There's just no point in worrying about
sub-nibble boundaries, and probably little point in worrying about
sub-octet boundaries.

OTOH, I kind of like the idea of an ICMP "what's your name" protocol, but,
I don't believe that would completely eliminate the need or desire for
ip6.arpa or in-addr.arpa.


> Oh, and I agree that anyone who can justify a /48 is definitely a
> business.
> 
I bet if Clan Campbell wanted to form their own family internet 
and build a series of links between households to facilitate a family
network
with a few points where it connected to the internet, you could argue that
a /48 was justified and that it wasn't technically a business.  However,
I would agree that is a corner case.

Owen



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060414/efa7d292/attachment.sig>