[ppml] IPv6>>32

[Jeff Williams]

Owen and all,

Owen DeLong wrote:

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

  Agreed.  And it would seem reasonable that definitive but still
flexible set of criteria should be delineated as to when such
an allocation when requested is justified and should be issued.

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

Also agreed here.  Still under what criterion such IDR assignments
are made needs to be delineated...

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

Also agreed here.  But it should be exacting as to form/language
so that the policy is easily understood and far less subject to
interpretation.

>
>
> Owen
>
> --
> If this message was not signed with gpg key 0FE2AA3D, it's probably
> a forgery.
>
>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: application/pgp-signature
>               Encoding: 7bit

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827