[170398] in North American Network Operators' Group
Re: IPv6 Security [Was: Re: misunderstanding scale]
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 27 02:23:08 2014
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20140327005039.GB7867@angus.ind.WPI.EDU>
Date: Wed, 26 Mar 2014 23:20:00 -0700
To: Chuck Anderson <cra@WPI.EDU>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 26, 2014, at 5:50 PM, Chuck Anderson <cra@WPI.EDU> wrote:
> On Wed, Mar 26, 2014 at 06:52:53PM -0500, Timothy Morizot wrote:
>> On Mar 26, 2014 6:27 PM, "Luke S. Crawford" <lsc@prgmr.com> wrote:
>>> My original comment and complaint, though, was in response to the
>> assertion that DHCPv6 is as robust as DHCPv4. My point is that =
DHCPv6
>> does not fill the role that DHCPv4 fills, if you care about tying an =
IP to
>> a MAC and you want that connection to persist across OS installs by
>> customers.
>>=20
>> You're right. DHCPv6 is more robust than DHCPv4. At least those of us =
in
>> the enterprise space appreciate a client identifier that doesn't =
change
>> when the hardware changes.
>=20
> No, it is LESS robust, because the client identifier changes when the
> SOFTWARE changes. Around here, software changes MUCH more often than
> hardware. Heck, even a dual-boot scenario breaks the client
> identifier stability. Worse yet, DHCPv6 has created a scenario where
> a client's IPv4 connectivity and IPv6 connectivity break under
> /different/ scenarios, causing difficult-to-troubleshoot
> half-connectivity issues when either the hardware is replaced or the
> software is reloaded.
Any client whose DUID changes on software re-install has a very poor =
choice of default DUID and should be configurable for a better choice of =
DUID. That is not DHCPv6=92s fault.
DHCPv6 is perfectly capable of behaving as you wish. Blaming the =
protocol for poor implementation choices by your (or your client=92s) =
vendors is a little odd in my opinion.
Owen
