[ppml] Universities (was IPv6>>32)

[Owen DeLong]

--On Saturday, May 14, 2005 11:03 -0400 Kevin Loch <kloch at hotnic.net> wrote:

> Owen DeLong wrote:
>> I think by default, each student should get a /64.  If, however, the
>> student expresses need for multiple subnets, then, I think a /48 is
>> exactly what was intended under the policy.
>
> It's not about wether a student needs 65k subnets, it's about wether
> they need 2.  Assigning 2 /64's to a student would violate current
> policy where assigning a /48 would not.
>
Right... However, why is that really a problem?  I can see some reasons
to potentially assign the student a /56, but, I think that /63s are
probably not a great idea if they can be avoided.

> Interestingly, while they could assign a /48 per _student_, they could
> not assign a /48 per _room_.  "Assignments" are made to legal entities
> and show up in swip/rwhois.  They only get one /48 per campus for their
> own infrastructure, so a /64 per room could be done but a /48 could not.
>
Sure it could.  Each room could be dubbed an organizational unit or 
department.

> If a University was sure they would not be assigning /48's to anyone
> (faculty, on/off campus students, vendors, commercial/industrial
> partners) then a /48 per campus would be all they need.  If they plan on
> assigning /48's then they should get a /32.
>
Right.  If they aren't going to be an LIR, then, they should get a /48.  If
they're going to function as an LIR, then, a /32 is in order.

> I expect most universities will eventually ask for and receive their
> own /32.  For that reason, reigonal networks that serve them should
> probably not get a large allocation (> /32) based on total downstream
> university customers.
>
I'm not so sure about that.  I think that universities that are not going
to act as LIRs should be counted as part of their upstream LIR customer
base for addressing.  Universities that do intend to act as LIRs should
get their own space from the RIR.

I don't think that is broken under current policy.

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/20050515/9347cf8e/attachment.sig>