[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] Issues with RFC 4361 reusing option 61
Yes, your suggested migration strategy of replacing the chaddr with the client ID in the reservation records will work. However, I don't follow your argument of why a new option number wouldn't work. There is no duality in case where the order of precedence is clearly defined.
DHCID-RR doesn't well for both dual-stacked and multi-homed scenarios. Even in single-stack cases (IPv4 alone), RFC 4701 implementations don't work in common scenarios such as laptops with both wired as well as wireless interfaces if clients don't implement RFC 4361.
-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf Of Ted Lemon
Sent: 18 March 2008 03:45
To: dhcwg at ietf.org WG
Subject: Re: [dhcwg] Issues with RFC 4361 reusing option 61
On 3/14/08 6:38 AM, "Mark Stapp" <mjs at cisco.com> wrote:
> but there are several ways to address the practical problem that
you're
> concerned about, right?
>
> - the database containing the reservations' client-id values could be
> updated programmatically (if there's an algorithm that can convert
a MAC
> to a DUID)
It seems to me that this is really the only correct way to do it. If
the client sends DUID-LLT, it's really easy, too. The way I would be
tempted to implement this is to have a flag on the server that enables
a transition mode. When this flag is on, the server first looks for
the client ding the DUID identifier. If it finds a client using the
DUID identifier, it proceeds normally.
If no such client is found, it constructs a client identifier option
using chaddr. It then uses this to look up a client record. If one
is found, it changes the client identifier on that record to be the
identifer the client actually sent. The client record is then used
to configure the client; the next time it hears from the client, the
record will be keyed off the new client identifier, and the migration
for that client will be complete.
> - the code in the affected servers could be updated to test chaddr
> instead of the client-id option value (that's the one I'd pick,
because
> you already have the database, and this way it'd still work)
This is broken, though - you can't claim to be following RFC4361 if
you do this.
> - the clients could send the old client-id value in, for example, a
> vendor-specific option, and the servers could test that value if it's
> present
Now you have a server that complies neither with RFC4361 nor with the
DHCP RFCs that it updates.
> - everyone involved could change to using some other identifier,
based
> on the user logged in, or the geographical location, or the
> department+building+floor+power socket+...
>
> none of those requires a _protocol_ change. they're just operational
> steps that'd be part of a migration plan. other than "scrap the
RFC," is
> there some protocol change or enhancement that you think would make a
> rollout that changes client-ids work better?
I think this is the key point. This is an operational issue, not a
protocol issue.
> Santosh Chandwani wrote:
>> IMO, a better way to address these deployment challenges would be
to use
>> a new option number for the DUID+IAID. This would allow for more
>> seamless migration and interop between older clients/servers which
>> assume the link-layer address is included in option 61, and newer
>> clients/servers which want to use the DUID+IAID.
This wouldn't work, which is why we didn't do that. The client
identifier is what identifies the client. RFC4361 does away with the
old duality of client identifiers, where you sometimes used chaddr and
sometimes used the client identifier option. Adding a third option
would have made this problem worse, not better.
>> Since RFC 4701 assumes that clients implement RFC 4361, this issue
also
>> blocks us from cleanly implementing DHCID-RR support.
This isn't true. Whether or not a client implements RFC4361, the
DHCID-RR should Just Work, because it doesn't care how the client
derived its identifier. 4701 doesn't assume anything; it just
doesn't work well if you have a dual-stack DHCPv4+DHCPv6 client that
doesn't follow RFC4361. For single-stack cases, it has no effect at
all.
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg