Help with DHCPv6 client-identifiers

[Simon Hobson]

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.