v6 subnet size for DSL & leased line customers

Iljitsch van Beijnum iljitsch at muada.com
Thu Dec 27 21:57:59 UTC 2007


On 27 dec 2007, at 20:26, Christopher Morrow wrote:

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

> first implementations, in a protocol that's 'fully baked' (according
> to ietf closing down the v6 WG) and been in 'production' for 15 years?

You suggest that I said that IPv6 has only recently seen the first  
implementations. I was talking about CGA/SEND, not IPv6 proper, which  
was standardized some 12 years ago.

> for features that have existed in the v4 network for 5+ years? ouch...
> This gets back to my point about having feature parity

Some of the "features" of IPv4 are actually glaring holes that some  
people have found a use for. Also, SEND is something that doesn't  
exist in IPv4 so your complaint doesn't apply here.

> and the fact
> that that is important. People have deployed rather large environments
> that require these features, not having them is a step backwards and
> painful for the operators in question.

Please direct your feature request to your favorite vendors...

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

> 'the largest deployed platform' already has this built-in, yes?  
> (vista/xp)

Vista: yes, it seems. XP, no so much. Windows XP can't even do DNS  
lookups over IPv6, which basically means that you can't use an XP  
machine on an IPv6-only network.

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

> you are crazy... seriously, have you walked around to 10k or 50k
> machines or attempted to get helpdesky people to do the same? have you
> considered that this all works fine in v4, is tied into my OSS
> backends and is a part of my business process? Getting some new
> software (firefox is a fine example) deployed to 50k workstations is
> an overnight event... SMS (or whatever the new MS equivalent is) rolls
> out the software update, there are many other options (tivoli,
> ca-unicenter, custom-foo) which will also do this work for you,
> getting proper and dynamic setup of IP info (my earlier example of
> resolvers) isn't quite as simple unless you use dhcp.

It is wih IPv6: you just connect the ethernet cable and the RAs take  
care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.  
If you need extreme control then manual configuration will give you  
that, which may be appropriate in some cases, such as servers.

> just saying 'dhcpv6 isnt possible use autoconf' is never going to be
> acceptable.

Never said it isn't possible. But unlike with IPv4, where DHCP is the  
default answer unless you're really sure you need manual  
configuration, DHCPv6 isn't the default answer for IPv6.

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

> also be sure to let your standards body(s) know that some form of
> feature parity is relevant. I think often there is a missing message
> between operators and the other folks :( this clearly (to me atleast)
> seems like one of those areas.

Taken to its extreme "feature parity" means a search and replace of  
all IPv4 specs to make every instance of "32 bits" "128 bits" but not  
changing anything else. That's not what IPv6 is.



More information about the NANOG mailing list