Help with DHCPv6 client-identifiers
Simon Hobson
dhcp1 at thehobsons.co.uk
Sat Nov 19 08:27:55 UTC 2011
Bjørn Mork wrote:
>I fail to see how you can expect to apply different policies to clients
>sharing the same media, unless you authenticate the clients somehow.
Then that is why you cannot see other's points of
view. You are equating this with security, I'm
not.
As you point out, unless you use a security
protocol then you can't rely on a lot of this,
but for a great many networks, it's not about
security, it's about management - and the MAC
address (for all it's faults) is "good enough".
> > And, the switch port changes a darn sight
>more frequently than the MAC address.
>
>In some situations, yes. But then you would want to use 802.1x.
Not if MAC address is good enough. MAC address
plus DHCP = works out of the box with ZERO client
config. 802.1x means client config overhead - and
if you have to configure your client, then what's
the purpose fo DHCP in your network ?
> > So your argument is that instead of using something that is
>> (nominally) unique and (largely) invariant, you want to use something
>> that is in fact fairly variable in most networks.
>
>My argument is the identifier you are choosing is under the client's
>control, which makes it unsuitable as a basis for any policy decision.
Only for the class of networks you are considering.
Incidentally, the same arguments apply for the
use of different DNS servers (ie different
classes of client get given different DNS
servers). It's not "security", but it deals with
some "soft" problems - ie it's "good enough" for
some people.
The impression I get is that the sort of people
for whom these are "good enough" weren't
represented in the standards making process, and
so the people who were there, were people who
didn't see (as you apparently don't) that it's
actually useful for some people.
> > So lets get this clear.
>> Instead of a setup where the cable modem has an identifier which needs
>> no configuration beyond the manufacturers giving it a unique ID (and
>> thereafter can be fully configured via DHCP), you propose a system
>> where the cable operator or their customers need to configure each
>> device before it is possible to configure it by DHCP.
>
>Yes, if you really need to identify the client, and you have chosen to
>build a network where the clients share a broadcast network, then I
>don't see any other option.
>
>You may of course choose to trust whatever the client tells you, but you
>may as well use the CLIENT_FQDN option or any other client configurable
>option. I still don't understand what you gain by such pseudo-
>authentication
Like I've already pointed out, the cable modem is
supplied by the cable company and comes from the
manufacturer pre-configured with a globally
unique identifier that can be used by any cable
operator whatever their system is built from.
They can stock these with no configuration
required, and can either read the identifier off
the box before shipping, or have the customer
read it to them when "turning it on" for services.
Nominally the customers doesn't have any access
to it, and there's not a lot they can do if they
do fiddle with the MAC address - worst case is
they duplicate another one on the network and
then neither work (which makes it visible to the
operator who can take action).
If you pre-configure an authentication string in
the modem, that means provisioning work == cost -
and by your logic the customer STILL can fiddle
with it. If the customer can change the MAC
address, then they've got enough access to change
the ID string.
So again, it might not be perfect, but it's
certainly "good enough" and actually has some
advantages.
Actually, what you are describing isn't that
different from the situation with ADSL networks
(at least in the UK, dunno about elsewhere). From
the authentication POV, it's a large network with
endpoints identified by username/password.
Typically the ISP supplies the customer with the
username & password, or they may pre-configure
the router. I can tell you from overhearing the
helpdesk at work, some support time is spent on
"have you put the right username & password in ?"
type conversations.
So it's not the panacea you put it forward as.
Alex Bligh wrote:
>>I have trouble understanding why this is a bad outcome, and what all the
>>vitriol is about. If RA is working fine for you, why do you care that
>>DHCPv6 is not?
>
>Autoconfig is quite inflexible in terms of addressing and netmasks which
>can be used. In particular, use of EUI64 means you end up giving the client
>a much bigger subnet than they need, and it is hard to allocate >1 IPv6
>address per NIC (i.e. per MAC) using this scheme without wasting yet more
>space. What we'd really like is to be able to allocate a fixed number
>of least significant bits (say 24) as "index of IP on one NIC", then the
>next (say 24) as "index of NIC on vLAN". Each vLAN would then get a /80.
>We could do have done that with DHCP or similar if it worked.
Ahh, I recognise this. You want pattern and
consistency (much as I do in my networks). In
effect, you want to be able to look at an
address, drop a few bits, and effectively have
something that identifies a customer's
machine(s). The alternative being that the only
way to tell them apart form others is to look
them up in the database **every** time.
Unfortunately, or fortunately depending on how
you look at it, IPv6 is going to force people to
fix their DNS (and management systems). I can
remember the IPv4 addresses of many of the
machine I admin at work, and for most of the
addresses in our public /24 I can at least recall
whether they are one of mine or one of the
Windows guys. That's not going to be the case
with IPv6 - we are all going to have to use DNS
because unless you are Rain Man, you aren't going
to remember IPv6 addresses.
Actually, I see this as a good thing. I find it
frustrating working with people who've only ever
worked on "small networks"* and really don't give
a **** about working DNS. They are happy to setup
printer connections by IP address, etc, etc, etc.
I think IPv6 will be hard enough to make it worth
sorting out working DNS.
* Not that I've worked on anything particularly large.
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the dhcp-users
mailing list