[ppml] IPv6>>32

[Owen DeLong]

> I would classify dorms as "student hotels" and assign a /64 per floor (or
> per building even) unless a student specifically asked for their own /64
> or /48.  Unfortunately, I'm not sure that's permitted under existing
> policy if the student is paying the university -- or if a guest is paying
> a hotel --  for Internet access.
> 
Regardless of whether they are apartments or hotels, this is, of course
permitted under current policy.  The policy doesn't say how you can or
cannot structure your networks.  What it does say is that if a subnet is
justified, the minimum subnet size is /64.  If multiple subnets are required
and the OU in question wishes to receive a self-managed allocation visible
in whois, then the minimum allocation unit is /48.  If an org is to become
an LIR, the minimum allocation unit is /32 and there are requirements to
justify that.  So, on simple request, one can receive a /48 or /64 or /128
depending on what one requests.  Above that, one must meet the requirements
of an LIR or provide sufficient justification to your LIR for additional
/48s.

> Extending this to the absurd, if the university (or other ISP) were
> offering service via 802.11, would we still require them to hand out a
> /48 per user/customer?  Are there even any consumer-grade devices that
> work in such a scenario?
> 
No ISP is required to hand out a /48 per customer.  They are, however,
required
to give a /48 to each customer that expresses need/desire for one.
I don't think this is absurd.

> The reality is that today and for the conceivable future a single human
> will only have a few to a few dozen devices needing a handful of addresses
> each -- and that's allowing for a lot of growth from today's norm of one
> IP per user -- which is well within the realm of simple, existing, cheap
> L2 technology.
> 
Actually, that's not entirely true.  I know several humans that use more
IP space than that even in existing IPv4.  I also know of lots of scenarios
where a lot more space than that is concealed behind NAT because of IPv4
constraints.

The reality is that more and more of our interdevice communication is
starting
to use IP for transport.  The additional reality is that more and more
interdevice communication is starting to be done (think ala universal
remotes,
or the ability of the coffee maker, oven, microwave, etc. to synchronize
the completion of breakfast, etc.).  The reality is that we know these
things are coming.  They're not speculative fruit cakes or fruit.  Also,
we've already seen the growing use of RFIDs and the desire of many users
to have them use IP.

The requirement for a /48 for every customer is absurd, but, it's also
inaccurate.  A customer may receive a /128, a /64, or a /48 at said
customer's discretion.  That's a good thing.  We can argue about where
those boundaries should be, but, giving each customer the ability to
get a host, a network, or a collection of networks at their discretion
is a good idea.

> We can throw around ideas of fruit crates (or even fruits) that need their
> own subnets for internal communication, but until such devices actually
> appear (and IMHO, it will not be within my lifetime), we shouldn't be
> wasting 80 bits of addressing on each human when only one to five bits
> will be used in the vast majority of cases.
> 
Fruit crates with IP based RFID tags do already exist.

>> If the person in charge of said device says that
>> a /64 is required, then I'm happy to give a /64.
> 
> Agreed.  But policy shouldn't _force_ people to deal with having their own
> /64 or /48 when they're happy getting one or more /128s out of a shared
> pool.
> 
It doesn't.  Nothing in the policy says you can't make that user a /128
within your /48 or allocate a /48 for such static assignments.

>> Simple rules of thumb can be applied to resolve these kinds of
>> issues.
> 
> ARIN doesn't operate on simple rules of thumb; it operates on policies.
> 
Right... The policy just specifies what you have to allocate on customer
request.  It doesn't say you have to allocate that to customers that don't
request it.

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/20050516/1e2493be/attachment.sig>