On Oct 24, 2010, at 6:48 AM, Leo Bicknell wrote:
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@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.
My understanding was DHCPv6 did support prefixes other than /64.
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.
Yeah, that could be worse than neutral. Still there's no gain to smaller than /64, only loss...
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.
I think that ship has pretty well sailed, but, it might be a good future workaround if providers start doing stupid pet tricks like assigning single /64s to end customers. Owen