[arin-ppml] Automatic IPv6 Eligibility

[Owen DeLong]

Not really… If you’re going to allocate smaller chunks, allocate sparsely, but that’s still
harmful in my opinion.

Developers will always develop to the lowest common denominator of home networking.

For example, I don’t run NAT at home for IPv4 (with a couple of minor exceptions for testing).

All of my internet-facing devices (including several desktops, audio amplifiers, TiVO, etc.) have
unique public IPv4 addresses.

There isn’t an application on the planet for any of these home media devices that can even
comprehend the basic idea of being able to reach the device directly rather than going through
some sort of polled rendezvous point to get past the NAT.

If we deploy small networks in a significant number of places, then that’s what developers
will develop for and innovation will again be stifled by arbitrary limitations that are unnecessary.

Owen

> On Aug 13, 2015, at 16:49 , John Santos <JOHN at egh.com> wrote:
> 
> 
> Sounds like "no one knows yet, so lets not shoot ourselves in the foot
> by underallocating prematurely"
> 
> Would it make more sense to allocate a smaller chunk, but sparsely?  If it
> turns out the smaller chunk suffices (e.g. a /60* is more than almost
> anyone needs), then the remaing 15 /60s** can be allocated to other
> users, but if everyone really needs a /56, the existing allocations
> can be bumped up in place (no renumbering, just access to a larger block.)
> 
> Or is 64 bits so huge that the mind can't cope and everyone really does
> need a /48 for home use and this won't force IPv7(?) with 512-bit addresses
> before anyone suspects?
> 
> Does every proton in the universe need its own subnet?
> 
> 
> * or a /56 or whatever
> 
> ** or the remaining 254 /56's as the case may be
> 
> 
> 
> On Thu, 13 Aug 2015, David Huberman wrote:
> 
>> ARIN does sparse allocation, where every /32 has 15 more /32s reserved for you (a /28).   Since almost no one really knows what they're doing yet (in my opinion; it's all first generation greenfield deployments we are doing), I say go ahead and give a /48 to each customer and re evaluate in the future when you have more data.  Being liberal with customers is better for them than being overly stingy. And you aren't harming the "free pool" since the first /32 is one sixteenth of what is already held for you.
>> 
>> Sent using OWA for iPhone
>> ________________________________________
>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of james machado <hvgeekwtrvl at gmail.com>
>> Sent: Thursday, August 13, 2015 4:15:18 PM
>> To: John Santos; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
>> 
>> John,
>> 
>> A /64 is just one network.  Arguments have been made that a smart
>> phone "needs" multiple /64's just to run IPv6 much less a "site" or
>> building.  The current fight is between a /56 and a /48 for each
>> customer as internal networking in v6 is going to happen.  Much
>> discussion has been happening on both Nanog and IPv6-ops mailing
>> lists.
>> 
>> James
>> 
>> On Thu, Aug 13, 2015 at 3:59 PM, John Santos <JOHN at egh.com> wrote:
>>> 
>>> Maybe off-topic, but the recommendation for assigning a /48 to each of
>>> the ISP's customers...  Does that apply only to business customers
>>> and organizations, etc., or does it also apply to residential customers?
>>> Why would a residence (unless they're network hackers like most of us)
>>> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
>>> use case for people subnetting their house or appartment :-)
>>> 
>>> I'm sure this has been discussed to death here and elsewhere.  I've not
>>> yet been involved in any large-scale IPv6 deployments (just our lone LAN
>>> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
>>> connectivity), so I'm trying to internalize IPv6 best practices before
>>> screwing up too badly.
>>> 
>>> --
>>> John Santos
>>> Evans Griffiths & Hart, Inc.
>>> 781-861-0670 ext 539
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
>> Please contact info at arin.net if you experience any issues.
>> 
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150813/c6d6c65f/attachment.htm>