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