IPv6 fc00::/7 ??? Unique local addresses
Leo Bicknell
bicknell at ufp.org
Sun Oct 24 13:48:57 UTC 2010
In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote:
> On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:
> > On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell <bicknell at ufp.org> wrote:
> >> There are some folks (like me) who advocate a DHCPv6 that can convey
> >> a default gateway AND the ability to turn off RA's entirely. That
> >> is make it work like IPv4.
> >>
> > I'd also love to turn off stateless autoconfig altogether and not be coerced
> > to assign /64s to single LANs, which I am becoming convinced that it was a
> > poor decision on the IETFs part.
> >
> Nah... The /64 thing is fine. If they hadn't done that, we likely would have only
> a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are
> fine.
I think the 64-bit boundry is fine (from a DHCP perspective). I
do think if we're going to update the DHCP spec it should support
a netmask option, just because leaving it out is short sighted to
the future, but I would use it with /64's today.
> There really is no need for anything smaller than /64. What, exactly, do you
> think you gain from a smaller netmask?
There is a slippery slope here, if users make do with smaller
providers may give out smaller blocks, and so on.
That said, if a provider does hand out a /64, I would very much
like technology to make 16 bits of subnet + 48 bits of host, with
EUI-48 used directly for autoconf as an option. Particularly when
we talk about 6rd and other things that use a lot of space this
option would be huge. Users would still get 16 bits of subnet, and
host space so big they could never fill it.
--
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20101024/4774c189/attachment.sig>
More information about the NANOG
mailing list