[ppml] IPv6>>32

[Owen DeLong]

> Don't be distracted by RFC 3177 using the terms "should" and "recommend";
> ARIN policy imports those suggestions and turns them into rules by
> omitting similarly liberal wording, even if that wasn't the intent -- and
> I think it was.  I don't see any leeway for an LIR to assign less than a
> /48 to "home network subscribers", which dorm residents certainly are.
>
I don't see the ARIN policy the same way you do.  I think it is equally
liberal to RFC 3177 and states that the summary is just that, a summary.
I don't see anything in the ARIN policy that says you MUST issue a /48
to such a subscriber, only that you can.

> I think the intent was to establish not only a maximum assignment, but
> also a minimum assignment.
>
I don't read it that way.  I read it as the intent was to establish maximum
assignments and a limited number of assignment sizes (e.g. /128, /64, /48,
and <=/32).  Whether those are the right limited sizes or not, I am not 
sure.
I think we will need more opex before we can determine that.  However, I do
think there is benefit to having a limited number of IDR assignment sizes
and having all of those sizes line up on octet boundaries.


> We'd have to drop the reference to RFC 3177 in that case, since it
> explicitly calls out SOHO users as deserving a /48 even if they don't ask
> for (or need) one.
>
I think that would be a mistake.  I think that the number of SOHO users that
need more than one /64 will increase, and, I think there was some good
reasoning behind RFC 3177.  I wouldn't mind seeing it possible to allocate 
/56
to such users, and, I wouldn't mind seeing what is currently a /64 become a
/32 (with a correspoonding 32 bit shift on everything else), but, there
seems to be substantial resistance to that for reasons I don't fully 
understand.
As such, I don't really see a need for more than some fine tuning to the
current policy in terms of sizing.

Owen



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- 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/20050517/7c311202/attachment.sig>