|
Replies:
9
-
Last Post:
Aug 16, 2006 5:31 AM
by: carlsonj
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Early DHCPv6 high-level design draft
Posted:
Aug 4, 2006 2:29 PM
|
|
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 <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 5, 2006 12:05 PM
in response to: carlsonj
|
|
James Carlson wrote:
>....
>
>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.
>
>
Will Solaris be enforcing the "must" and "should" words in the
above two paragraphs?
That is, if a system has been manually configured for a network
and then receives a message indicating that it should/must use
DHCPv6, will it then over ride the existing configuration params?
>...
>Interoperability
>
> Several different servers need to be checked out, including
> Wide-DHCP, Dibbler, and (if available) ISC's.
>
>
Is Cisco relevant here?
>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.
>
>
Microsoft? IPv6 appears to be a native part of XP and
appears to always be enabled on an interface. Unless
you take action to specifially disable it on a NIC, I think
you would find it enabled by default on just about any
XP PC.
Is it worth mentioning anything about Zones in this document?
Or, for that matter, stack instances?
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 5, 2006 12:19 PM
in response to: darrenr
|
|
Darren Reed writes:
> > 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.
> >
> >
>
> Will Solaris be enforcing the "must" and "should" words in the
> above two paragraphs?
>
> That is, if a system has been manually configured for a network
> and then receives a message indicating that it should/must use
> DHCPv6, will it then over ride the existing configuration params?
What configuration parameters?
Actually, I think the right answer is that the existing in.ndpd
configuration should be extended to include a "StatefulAddrConf"
parameter, just like the existing StatelessAddrConf.
I'll add that.
> > Several different servers need to be checked out, including
> > Wide-DHCP, Dibbler, and (if available) ISC's.
> >
> >
>
> Is Cisco relevant here?
Likely, yes. IPv6 on Cisco routers can be a bit hard to come by in
the test labs we have, though.
> >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.
> >
> >
>
> Microsoft? IPv6 appears to be a native part of XP and
> appears to always be enabled on an interface. Unless
> you take action to specifially disable it on a NIC, I think
> you would find it enabled by default on just about any
> XP PC.
Yes. Actually, the issue here is mostly with the configuration
interface and behavior, so non-UNIX platforms are a little less
interesting, but still worth a check.
> Is it worth mentioning anything about Zones in this document?
> Or, for that matter, stack instances?
I should have a separate section for related Open Solaris projects.
For Zones, there's no support for DHCP right now and little IPv6
support. If we support it in the future, then this feature should be
enhanced to support Zones as well.
For stack instances, it should all "just work." I don't think there's
anything special to do there.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 6, 2006 9:11 AM
in response to: carlsonj
|
|
On Fri, 4 Aug 2006, James Carlson wrote:
> draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt
This draft has been superceded, version 6 was published as standards
track RFC3633.
I have an interest in this RFC, wrt supporting it for Quagga's RA
sender-side code. (I've no idea though how one would manage interaction
between such support in Quagga and with any existing system DHCPv6
clients..).
regards,
--
Paul Jakma,
Network Approachability, KISS. Sun Microsystems, Dublin, Ireland.
http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 7, 2006 8:00 AM
in response to: paulj
|
|
Paul Jakma writes:
> On Fri, 4 Aug 2006, James Carlson wrote:
>
> > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt
>
> This draft has been superceded, version 6 was published as standards
> track RFC3633.
Yep; the list is stale. I'll update.
> I have an interest in this RFC, wrt supporting it for Quagga's RA
> sender-side code. (I've no idea though how one would manage interaction
> between such support in Quagga and with any existing system DHCPv6
> clients..).
Fortunately for me, the RA sender-side has nothing to do with this
project, as I'm implementing the client-side functionality. ;-}
I agree that there are some deep architectural problems with IPv6, and
that this issue -- entanglement of router discovery with addressing
policies -- is one exposure of those problems. Another is the
extremely strange 'R' bit in the Neighbor Advertisement message, which
ties together routing and NDP in not-completely-documented-or-
understood ways. (Perhaps that should just be IFF_ROUTER ... but even
that runs into trouble on hosts with virtual IP addresses.)
It's almost as if the protocol assumes a monolithic software
architecture. ;-}
Anyway, I would assume that if you're planning to put in server-side
code for RA, then you're also ripping out the server-side code that
already exists in in.ndpd and subsuming that functionality. If you're
not, then I'm not sure I see how Quagga will be reliable in such a
network. It seems like the two would be prone to conflict.
At the point where you're taking over RA functionality, I think that
means you also end up taking over the basic network configuration
broadcasting -- i.e., the setting of the 'M' and 'O' bits for the
network.
Other than simple commands ("set ipv6 stateful-addresses true"?) and
extensive user documentation (and risk of escalations when things fall
apart), I'm at a loss to see how to tie these things together
properly. It seems like it'd be best if the DHCPv6 server could
somehow "tell" Quagga whether it should say something about address
management. I don't know the right way to do that.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 8, 2006 2:02 AM
in response to: carlsonj
|
|
Hi Jim,
On Mon, 7 Aug 2006, James Carlson wrote:
> Fortunately for me, the RA sender-side has nothing to do with this
> project, as I'm implementing the client-side functionality. ;-}
:)
Just to stress, none of this is any immediate obstacle to DHCPv6,
but its worth having a quick think about it at least.
> I agree that there are some deep architectural problems with IPv6, and
> that this issue -- entanglement of router discovery with addressing
> policies
Yeah, the whole collision of DHCP an RA in IPv6 is annoying actually.
> -- is one exposure of those problems. Another is the
> extremely strange 'R' bit in the Neighbor Advertisement message, which
> ties together routing and NDP in not-completely-documented-or-
> understood ways.
To allow prompt detection of routers that stop being routers, according
to the RFC ;).
> It's almost as if the protocol assumes a monolithic software
> architecture. ;-}
Where ever would such an assumption come from? :)
> Anyway, I would assume that if you're planning to put in server-side
> code for RA, then you're also ripping out the server-side code that
> already exists in in.ndpd and subsuming that functionality.
That'd seem the right thing to do, in such a case.
> Other than simple commands ("set ipv6 stateful-addresses true"?) and
> extensive user documentation (and risk of escalations when things fall
> apart),
Yes, it has such commands, to control M and O in RAs sent.
> I'm at a loss to see how to tie these things together properly. It
> seems like it'd be best if the DHCPv6 server could somehow "tell"
> Quagga whether it should say something about address management. I
> don't know the right way to do that.
Well the worry is, I guess, given how that RFC throws together DHCP
server, client and RA sender (for the requesting router at least), how
to make them play nice together. Which isn't a question we can answer
here, is it?
Actually, maybe there's a deeper question here generally of various
routing and addressing services generally being unaware of each other,
not always blissfully (and, it seems, ever less blissfully with time as
new technologies/requirements/user-expectations come along).
regards,
--
Paul Jakma,
Network Approachability, KISS. Sun Microsystems, Dublin, Ireland.
http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 10, 2006 3:19 PM
in response to: carlsonj
|
|
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 10, 2006 5:45 PM
in response to: dminer
|
|
Dave Miner writes:
> > 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.
No, I hadn't; thanks for mentioning it. I haven't started looking yet
at the outstanding RFEs. (Right now, I'm looking at the detailed
design.)
Yes, it seems reasonable to include that, and I'll look into it.
The RFC recommends making the system default to having the same
binding association (client ID) for v4 and v6. I'm not so sure that's
wise, as it means that we'll not only break existing configurations,
but also existing DHCP server configuration tools.
I think that compatibility will be the sticking point here. The rest
of it looks fairly straightforward.
(Looks like Bill missed author's last call on his name ... :-/)
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 15, 2006 10:02 PM
in response to: carlsonj
|
|
> > 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.
>
> No, I hadn't; thanks for mentioning it. I haven't started looking yet
> at the outstanding RFEs. (Right now, I'm looking at the detailed
> design.)
>
> Yes, it seems reasonable to include that, and I'll look into it.
>
> The RFC recommends making the system default to having the same
> binding association (client ID) for v4 and v6. I'm not so sure that's
> wise, as it means that we'll not only break existing configurations,
> but also existing DHCP server configuration tools.
Agreed. However, is there a possibility this be used to provide client
ID's when performing DHCP over IPv4 logical interfaces? This has been one
of the issues associated with making DHCP feasible in a zone.
> (Looks like Bill missed author's last call on his name ... :-/)
But at least the "Authors' Addresses" information is correct, ensuring
limitless SPAM :-)
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Early DHCPv6 high-level design draft
Posted:
Aug 16, 2006 5:31 AM
in response to: meem
|
|
Peter Memishian writes:
> > The RFC recommends making the system default to having the same
> > binding association (client ID) for v4 and v6. I'm not so sure that's
> > wise, as it means that we'll not only break existing configurations,
> > but also existing DHCP server configuration tools.
>
> Agreed. However, is there a possibility this be used to provide client
> ID's when performing DHCP over IPv4 logical interfaces? This has been one
> of the issues associated with making DHCP feasible in a zone.
Yes, that's feasible. We'd likely want to set up a known DUID space
for zones.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
