James R Cutler
james.cutler at consultant.com
Tue Dec 22 18:04:13 UTC 2015
> On Dec 22, 2015, at 12:47 PM, Owen DeLong <owen at delong.com> wrote:
>> On Dec 22, 2015, at 01:21 , Bjørn Mork <bjorn at mork.no> wrote:
>> Owen DeLong <owen at delong.com> writes:
>>>> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog at ics-il.net> wrote:
>>>> The idea that there's a possible need for more than 4 bits worth of
>>>> subnets in a home is simply ludicrous and we have people advocating
>>>> 16 bits worth of subnets. How does that compare to the entire IPv4
>>> I have more than 16 subnets in my house, so I can cite at least one
>>> house with need for more than 4 bits just in a hand-coded network.
>>> Considering the future possibilities for automated topological
>>> hierarchies using DHCP-PD with dynamic joining and pruning routers, I
>>> think 8 bits is simply not enough to allow for the kind of flexibility
>>> we’d like to give to developers, so 16 bits seems like a reasonable
>> Thanks for summarizing why /48 for everybody is possible. But I fear
>> that is not helping much against arguments based on "need". I believe it
>> is difficult to argue that anyone needs any IP address at all, given
>> that there are lots of people in the world who seem to survive just fine
>> without one…
> Arguments based on “need” don’t make any sense in an IPv6 context.
> Sure, we shouldn’t be so profligate in our distribution of the address pool
> that we run out well before the protocol’s useful life is exhausted, but I
> think I’ve shown that the current allocation policies, including /48 have
> adequate protection against that occurring.
> Being more restrictive just for the sake of being more restrictive doesn’t
> serve any purpose. It doesn’t help anyone. As such, I just don’t understand
> those arguments. If someone can show me a tangible benefit from a more
> restrictive policy, I’m open to considering it, but so far, none exists.
The best feature of being more restrictive is continuing employment of people and processes for restriction.
The worst feature of being more restrictive is paying for the extra people and processes.
If we standardize on /48 (or whatever) then we can put all that money and labor into solving the real business problems of the IPv6 Internet..
>> So, with that sorted out, let's consider what you can do with 16 bits of
>> subnets. One example is checksum neutral prefix translation (RFC6296)
>> without touching the interface id bits . Let's say you have two upstream
>> ISPs handing you the prefixes A/48 and B/56. Neither offer any
>> multihoming support to residential users and both do BCP38 of course. So
>> you use B/56 internally and do prefix translation to allow your router
>> to select upstream without involving the clients. Thanks to the A/48
>> from the first ISP, you are able to choose a set of 256 (or possibly 255
>> since 0xffff cannot be used) checksum neutral subnet pairs.
> That’s a really icky alternative to simple BGP multihoming (which is what
> I’m currently using at home).
> Of course, not the worst, but a significantly bad part of this is the provider
> that’s only giving you a /56 to begin with. ;-)
>> Yes, I know. Evil. No need. No CPE support. Etc.
> True that.
>> The important part is that 16 bits of subnets is enough to play
>> algorithmic tricks with the subnet part of your address too, whereas
>> this is much more difficult with fewer bits. No, you don't need to do
>> it. But you CAN. The sparse IPv6 addressing model is about opening up
>> possibilities. Note that those possibilities includes restricting
>> yourself to using a single address. You don't have to use all your 2^80
>> addresses :)
> I completely agree.
>> And for the ISPs, using /48 for every user means fewer prefix lengths to
>> consider for routing and address management. Sure, we manage diverse
>> prefix lengths in IPv4 today, but why not take advantage of this
>> possible simplification if we can? Only those living on bugs will object
>> to simpler address databases and routing filters.
> Again, you’re preaching to the choir.
More information about the NANOG