One question about the section below:
DUID and IAID
In DHCPv6, two identifiers are used. The DUID is the classical
variable-length "opaque" client identifier, and the IAID is a 32 bit
integer.
Normally, the DUID will be autogenerated (using Type 1) and stored
in /var/inet/dhcpv6 in order to meet the stability requirements of
RFC 3315. The IAID will default to the ifIndex number for the
physical interface being configured, as that's guaranteed by the
kernel to be unique for all physical interfaces.
In ordinary use, the same DUID is used on all interfaces, and the
IAID identifies a particular physical interface being configured.
The user may need to set these values for special purposes,
including for software test. In order to allow for that, we will
use the existing CLIENT_ID variable in dhcpagent to provide override
control of the DUID, and add a new IAID variable that can be set on
a per-interface basis only.
The DUID has a known structure, and we will support these types
using a comma-separated string, as follows:
1,<type>,<lla> Type 1, DUID-LLT. The <type> value is a 16
bit integer (0-65535), and the <lla> is either
a colon-separated MAC address or the name of a
physical interface. The time value required
for this format is queried automatically and
kept in the /var/inet/dhcpv6 state file.
2,<ent>,<hex> Type 2, DUID-EN. The <ent> value is a 32 bit
integer, and <hex> is an even-length string of
hexadecimal digits.
3,<type>,<lla> Type 3, DUID-LL. This is the same as
DUID-LLT, except that a time stamp is not
used.
*,<hex> Any type value 0 or 4-65535 may be used with
an even-length hexadecimal string.
The new (optional) IAID value will just be a simple integer.
Will the above support using the DUID/IAID form of a client ID for
DHCPv4 as well, per RFC 4361? I had filed 6386331 some time back to
record that we should look into this issue. The above text seems
slightly DHCPv6-specific, so I'm guessing you haven't scoped that in yet.
Dave
Logical Interfaces
In the IPv4 DHCP client, each logical interface is independent and
is an administrative unit. In addition to the zeroth logical
interface (which defaults to the interface MAC address as an
identifier), the user may configure specific logical interfaces to
run DHCP by specifying a CLIENT_ID in the dhcpagent configuration
file. For example:
hme0:1.CLIENT_ID=orangutan
DHCPv6 will be different. The zeroth logical interface on an IPv6
interface, unlike IPv4, is always a link-local. It cannot be under
DHCP control, which means that DHCPv6 is run only on non-zero
logical interfaces.
In addition, the DHCPv6 server will send back a list of addresses
for the client to configure. In Solaris, each of these addresses
requires a separate logical interface. On top of that, stateless
address configuration already creates logical interfaces as required
(using an "ifconfig addif"-like interface).
All of the above means that the logical interface cannot be the
administrative unit in DHCPv6. Instead, the administrative unit is
known as the "Identity Association," and is a handle for the client
identifier, physical interface, and all of the configured addresses.
In order to allow for configurable client operation, we need to
allow for DUIDs to be assigned as needed, even on a per-interface
basis. This may be used to set the global DUID as:
.v6.CLIENT_ID=<DUID>
or to set a particular interface to use a given DUID (and make the
system appear to be multiple independent clients to a DHCPv6
server):
hme0.v6.CLIENT_ID=<DUID>
Note that setting parameters on a single logical interface does not
make sense with DHCPv6, thus "hme0:1.v6." isn't a valid selector.
It would be possible to support an administrative unit that works in
a way analogous to logical interfaces for DHCPv6. To do this, we
would need a way to name contexts used for separate DUIDs on a
single physical port; perhaps using something like the logical
interface naming scheme. However, no known usage case exists for
this feature, so it need not be designed in detail now.
DLPI
Because DHCPv6 uses link-local addresses, it's not necessary for the
agent to do any raw DLPI processing. None of the existing DLPI
processing in dhcpagent will be touched, nor should DLPI support be
needed in the future.
Client Broadcast
All messages sent to a DHCPv6 client are (currently) unicast, so
it's not necessary to support a separate broadcast or multicast
bound socket, as is currently done for IPv4 DHCP. It's possible
that some future extensions to DHCPv6 may need this support.
Standalone
There is no DHCPv6-based install support, so none of the DHCP
support functions need to be placed under $SRC/common. This may be
necessary in the future.
Interoperability
Several different servers need to be checked out, including
Wide-DHCP, Dibbler, and (if available) ISC's.
Comparisons
TBD: need to check how Linux configures DHCPv6. Based on the
documentation, it doesn't look like it conforms with the RFCs,
because it doesn't seem to be controlled by the RA bits. Instead,
it appears to be manually configured.
Should also check other vendors (IBM, HP) if possible.
Drafts To Ponder
draft-ietf-dhc-dhcpv6-28.txt
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt
draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt
draft-ietf-dhc-dhcpv6-stateless-00.txt
_______________________________________________
networking-discuss mailing list
[email protected]
