v6 subnet size for DSL & leased line customers

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Thu Dec 27 12:11:58 UTC 2007

On Thu, 27 Dec 2007 11:27:13 +0100
Iljitsch van Beijnum <iljitsch at muada.com> wrote:

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


> > 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  
> implementations.
> 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.

I think it's interesting CGAs are being discussed in the same email as
the one where you say you want to be able to express prefix length in DHCPv6 -
because I'm guessing you want that feature to be able to shorten node

One of the benefits of fixed length node addresses, at the 64 bit
boundary, is that it has made CGA much simpler - the CGA designers knew
from the outset that they were dealing with a single, fixed length 64
bit field to store the results of their crypto functions. If people had
different length autoconfigured or DHCPv6 learned addresses, not only
would CGA have to had be designed to support those varying field
lengths, increasing it's complexity (and therefore increasing
opportunities for implementation related security failure aka bugs with
security consequences), it's also likely that CGA would have had to
incorporate parameter checks to prevent people enabling it, when the
node address length they've chosen is too short for the security
strength CGA is designed to provide. If you don't perform these sorts
of checks, then too weak CGA, because of too short node addresses,
might give people a false sense of security - and I think that's far
worse than no security at all.



        "Sheep are slow and tasty, and therefore must remain constantly
                                   - Bruce Schneier, "Beyond Fear"

More information about the NANOG mailing list