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.
|
muada.com> wrote:
>
> On 27 dec 2007, at 20:26, Christopher Morrow wrote:
>
<snip>
>
> 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.
Exactly.
IPv6 is similar enough to IPv4 that it makes it easier to
learn than if
it were a completely new and unrelated protocol.
It's different enough that you need to take each of the
concepts and
practices that you know and have used for IPv4 for many
years and try
to objectively evaluate whether they're still valid for
IPv6. IPv6 has
features that IPv4 has never had, but have existed in IPX
and Appletalk
since they were designed many years ago. If people have the
time,
learning about those protocols might help with more easily
learning
about IPv6.
Regards,
Mark.
--
"Sheep are slow and tasty, and therefore must
remain constantly
alert."
- Bruce Schneier,
"Beyond Fear"
