v6 subnet size for DSL & leased line customers

Iljitsch van Beijnum iljitsch at muada.com
Thu Dec 27 10:27:13 UTC 2007

On 26 dec 2007, at 22:40, Leo Bicknell wrote:

> If you're a shop that uses such features today (MAC/Port tracking,
> DHCP snooping, etc) to "secure" your IPv4 infrastructure does IPv6
> RA's represent a step backwards from a security perspective?  Would
> IPv6 deployment be hindered until there is DHCPv6 snooping and
> DHCPv6 is able to provide a default gateway, a-la how it is done
> today in IPv4?

> It would be very interesting to me if the answer was "it's moot
> because we're going to move to CGA's as a step forward"; it would
> be equally interesting if the answer is "CGA isn't ready for prime
> time / we can't deploy it for xyz reason, so IPv6 is less secure
> than IPv4 today and that's a problem."

With IPv4, a lot of these features are developed by vendors and  
(sometimes) later standardized in the IETF or elsewhere. With IPv6,  
the vendors haven't quite caught up with the IETF standardization  
efforts yet, so the situation is samewhat different. For instance,  
SEND/CGA is excellent work, but we've only recently seen the first  

Personally, I'm not a big fan of DHCPv6. First of all, from a  
philosophical standpoint: I believe that stateless autoconfiguration  
is a better model in most cases (although it obviously doesn't support  
100% of the DHCP functionality). But apart from that, some of the  
choices made along the way make DHCPv6 a lot harder to use than DHCP  
for IPv4. Not only do you lack a default gateway (which is actually a  
good thing for fate sharing reasons) but also a subnet prefix length  
and any extra on-link prefixes. So even if you do address  
configuration with DHCPv6 you need RAs for that other information.  
There's also tons of ways to complicate your life by mixing stateless  
autoconf and DHCPv6, especially since most systems don't support  
DHCPv6 unless you install additional software. Last but not least,  
DHCPv6 has a stateful mode that's appropriate for address assignment  
or prefix delegation, and a stateless mode that's more efficient for  
the configuration of information that's not client-specific.  
Unfortunately, it's up to the client to initiate the desired mode.  
Then there are the M and O bits in RAs that tell you whether to do  
DHCPv6 but a number of DHCPv6 aficionados look like they want to  
ignore those bits.

What this all boils down to is that if you want to deploy DHCPv6 you  
need to install software on a lot of systems and modify a lot of  
configurations. If you're going to do all that, it's easier to simply  
configure this stuff manually. The only downside to that is that it's  
not compatible with easy renumbering, but then, you need to do more  
than just automate address assignment to support easy renumbering.

I don't think IPv6 address configuration in general and DHCPv6 in  
particular will ever be fully equivalent to how things work with IPv4.  
This is really the place where the differences between the two  
protocols are the biggest. For those of us who are familiar with IPX,  
AppleTalk, CLNP and IPv4: IPv6 basically uses the address  
configuration methods from all of those, no wonder it can get a bit  

That being said, please go to your vendors and tell them what you  
need. Preferably at a high level, so they can provide the  
functionality in the optimal way, rather than just revert back to the  
IPv4 way of doing things.

More information about the NANOG mailing list