[186539] in North American Network Operators' Group
Re: Nat
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Dec 22 12:50:02 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <8737uurg8d.fsf@nemi.mork.no>
Date: Tue, 22 Dec 2015 09:47:44 -0800
To: =?utf-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Dec 22, 2015, at 01:21 , Bj=C3=B8rn Mork <bjorn@mork.no> wrote:
>=20
> Owen DeLong <owen@delong.com> writes:
>>> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog@ics-il.net> wrote:
>>=20
>>> 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
>>> Internet?
>>=20
>> 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.
>>=20
>> 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=E2=80=99d like to give to developers, so 16 bits seems like a =
reasonable
>> compromise.
>=20
> 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=E2=80=A6
Arguments based on =E2=80=9Cneed=E2=80=9D don=E2=80=99t make any sense =
in an IPv6 context.
Sure, we shouldn=E2=80=99t be so profligate in our distribution of the =
address pool
that we run out well before the protocol=E2=80=99s useful life is =
exhausted, but I
think I=E2=80=99ve 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=E2=80=99t
serve any purpose. It doesn=E2=80=99t help anyone. As such, I just =
don=E2=80=99t understand
those arguments. If someone can show me a tangible benefit from a more
restrictive policy, I=E2=80=99m open to considering it, but so far, none =
exists.
> 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=E2=80=99s a really icky alternative to simple BGP multihoming =
(which is what
I=E2=80=99m currently using at home).
Of course, not the worst, but a significantly bad part of this is the =
provider
that=E2=80=99s 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.
>=20
> 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=E2=80=99re preaching to the choir.
Owen
