This is a _very_ early DHCPv6 high-level design draft -- too drafty
even for the web page. It doesn't go into implementation details
(much), but does give a feel for the direction I'm currently headed.
If anyone else out there is interested in DHCPv6, please feel free to
comment, either here on the list or to me personally if you prefer.
DHCPv6 Client High-Level Design
This document describes the high-level design and system
architectural issues involved in the DHCPv6 Client project. A
separate document will describe the low-level design, including the
internal state machine operation.
The overall goal is to add DHCPv6 into the existing Solaris DHCP
client support. This means extending the existing utilities as
necessary to support the new protocol and its features, and avoiding
gratuitous differences where possible. In some respects, DHCPv6 is
quite different from IPv4's DHCP, and the design must reflect those
differences.
Configuration Syntax
We would like to allow for configuration of the DHCPv6 client in
much the same way as the existing IPv4 DHCP client is configured.
This means using /etc/default/dhcpagent.
One option would be to create a new "dhcpv6agent" file, and using a
separate set of configuration bits there. However, given that these
parameters are rarely configured, and that splitting IPv4 and IPv6
configuration interfaces has historically caused confusion, we will
simply add a new syntax to the existing file.
The syntax is augmented to allow a ".v6" marker to appear between
the interface name (if any) and the parameter to be configured. For
example, the global IPv4 option request list would (currently) be
set like this:
PARAM_REQUEST_LIST=1,3,6,12,15,28,43
An individual interface could be configured to omit the pesky
hostname option like this:
hme0.PARAM_REQUEST_LIST=1,3,6,15,28,43
For DHCPv6, the global request list will be set like this (note the
leading dot):
.v6.PARAM_REQUEST_LIST=23,24
or on an individual interface like this:
hme0.v6.PARAM_REQUEST_LIST=21,22,23,24
Router Advertisements
Unlike DHCPv4, DHCPv6 is expected to be invoked by Router
Advertisements (RAs), rather than by manual configuration (see RFC
2462). When the system receives an RA with the ``M'' ("managed
address configuration") bit set, the system should automatically
invoke DHCPv6 on that interface and use it to get an address and
other parameters. The ``O'' ("other stateful configuration") bit
indicates whether the system should only request data other than an
address (e.g., DNS servers) via DHCPv6.
If either bit is set, we must run DHCPv6. When triggered by way of
RA, we acquire an address lease only if the ``M'' bit is set.
In addition, it's expected (per RFC 2462) that DHCPv6 will be
invoked if no RAs are received at all on a given interface. Running
DHCPv6 ``should'' effectively be the system-wide default for every
interface.
Note that stateless and stateful address configuration are
independent, and both may be used on a given link. The stateless
address configuration mechanism is controlled by the ``A'' bit in
the Prefix Information option -- see RFC 2461 section 4.6.2.
Two design issues to resolve here are that the ``ra_flags'' variable
in ndp.c is implemented as a global, when the RFC specifies that it
must be per-interface, and that in.ndpd doesn't detect and handle
the state where no RAs are received (though it does have comments
saying that "something" should happen).
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.
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
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
