Subject: [dhcwg] Minutes from meeting in SLC, 12/10

From: Ralph Droms <[email-masked]>
Date: Mon, 07 Jan 2002 13:16:58 -0500

Here are draft minutes from the WG meeting in SLC.  Please review and reply 
with comments by Wednesday, 1/12.  Thanks...

- Ralph

=====

		    DHC WG meeting, Salt Lake City
			      12/10/2001

These minutes were prepared by Ralph Droms, based on notes from Ted
Lemon and Stuart Cheshire.

DHC WG activities update, Ralph Droms
-------------------------------------

The DHCP FORCERENEW message, for server-initiated client
configuration, has been published as RFC 3203.

The DHCP Failover Protocol spec <draft-ietf-dhc-failover-10.txt>, and
Subnet Selection sub-option for the Relay Agent Information Option
spec <draft-ietf-dhc-agent-subnet-selection-01.txt> are both ready for
IETF last call.

Encoding Long DHCP Options <draft-ietf-dhc-concat-02.txt> and The
Classless Static Route Option for DHCP <draft-ietf-dhc-csr-06.txt> are
with the Internet Area Directors for submission to the IESG.

The DHCP Domain Search Option <draft-aboba-dhc-domsearch-08.txt> is
ready for publication, awaiting publication of Encoding Long DHCP
Options <draft-ietf-dhc-concat-02.txt> to resolve a normative
reference.  Thomas Narten pointed out that there is a serious security
problem with configuration of the domain search list: an attacker
might configure a host with a domain search list that can cause names
to be resolved silently to unexpected targets; e.g., a reference to
"my-webserver" would be resolved as "my-webserver.attackersite.com".
Narten noted that DNSSEC can't solve this problem, as the DNS name
(which points unexpectedly at the attacker host) is resolved
correctly.

VPN Identifier sub-option for the Relay Agent Information Option
<draft-ietf-dhc-agent-vpn-id-01.txt>, Kim Kinnear
----------------------------------------------------------------

Draft has no substantive changes; updates include an improved IANA
considerations section and later expiry times.  WG requested no
additional changes prior to WG last call.

DHCP VPN Information option <draft-ietf-dhc-vpn-option-00.txt>,
Richard Johnson
---------------------------------------------------------------

This option is essentially identical to VPN Identifier sub-option for
the Relay Agent Information Option. WG requested no additional changes
prior to WG last call.

DHCP Lease Query <draft-ietf-dhc-leasequery-02.txt>, Kim Kinnear
----------------------------------------------------------------

-03 draft was submitted but not published before IETF 52 due to mailer
problems.  The current draft needs to be revised slightly to support
multiple queries in a single option, because this behavior is implied
by Encoding Long DHCP Options <draft-ietf-dhc-concat-02.txt>.  -04
draft should be ready for WG last call.  Kinnear reported that there
is a need to move quickly on this draft, as there are implementors
waiting to find out the TBD values before completing implementations.

Dynamic Host Configuration Protocol (DHCP) Server MIB
<draft-ietf-dhc-server-mib-07.txt>, Barr Hibbs
-----------------------------------------------------

The latest draft includes minor revisions.  Security has been made
easier through the removal of ability to send some MIB elements.  Many
other simplifications, removing and simplifying variables deemed to be
of limited usefulness.  Next rev will be ready for WG last call.

DHCP Load Balancing Algorithm for IPv6, Bernie Volz
--------------------------------------------------

Volz proposed to extend DHCP load balancing to IPv6.  Two questions:
what should be used as the hash key and how should the servers behave
when the client is not in the server's hash bucket?  Narten said that
the IESG was unhappy with the DHCPv4 load balancing behavior, in which
a server drops requests not in its bucket, because there is no
recovery mechanism in response to a server failure.  Volz suggested
that DHCPv6 load balancing set the server preference; Ted Lemon
replied that the result would not be "load balancing".  Vloz to take
the discussion to the mailing list.

IPv4 Address Conflict Detection <draft-cheshire-ipv4-acd-00.txt>,
Stuart Cheshire
-----------------------------------------------------------------

Cheshire's draft captures, precisely defines and clarifies address
conflict detection in IPv4.  This mechanism is used, for example, in
the DHCP spec.  Cheshire's goal is to document IPv4 address detection
in one place to be referenced by other specs.

Kim Kinnear asked if this draft should be a DHC WG draft?  Cheshire
wondered if DHC is the right place, as other WG specs will reference
his doc.  Narten opined that DHC WG would be OK, as this WG has
significant experience with the problem.  Narten suggested that the
document carefully document motivation for details such as timeouts,
and document exceptions to SHOULDs and MUSTs.

Qualifying the Root Path Option for iSCSI Boot
<draft-sarkar-dhc-iscsi-boot-00.txt>, Prasenjit Sarkar
------------------------------------------------------

Sarkar's draft describes a way to use the root-path option for passing
a text string containing the IP address and target ID for iSCSI boot
device.  WG consensus was that proposed encoding fits within current
definition of root-path option, so the encoding can be defined in the
IPS WG document about iSCSI boot and no separate DHC WG document is
required.

802.1X Credentials Sub-option for the DHCP Relay Agent Information
Option <draft-droms-agentopt-8021x-00.txt>, John Schnizlein,
Ralph Droms
------------------------------------------------------------------

Schnizlein and Droms have defined a new agent information suboption
that carries 802.1x authentication credentials from a relay agent to a
DHCP server.  Once the 802.1x authentication has been completed and
the port turned on, the relay agent can send the 802.1x authentication
credentials to the DHCP server, which the DHCP server can then use,
for example, to identify the DHCP client.  WG agreed to take this spec
on as a WG item.  Authors to update draft, changing "credentials" to
"identity information" and other changes based on WG input.

Use of the Host Name option for inferred DNS updates by DHCP servers,
Carl Smith, Ted Lemon
---------------------------------------------------------------------

Smith and Lemon proposed writing a document that specifies the use of
the Host Name option for DNS updates by DHCP servers.  The purpose of
the document would be to capture current practice in a clarification
and precise specification.  The WG agreed to take this specification
as a WG work item.

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
<draft-ietf-dhc-dhcpv6-21.txt>, Jim Bound, Ralph Droms
------------------------------------------------------

WG discussed the -21 draft.  Authors' plan is to revise spec based on
input from WG and publish -22 draft.  -22 draft will then be submitted
for WG last call.  Narten pointed out that 3GPP spec has normative
reference to DHCPv6 and needs DHCPv6 spec by March, 2002.

Primary change in -21 draft is modification to text on identity
associations.  New text, with scoped options for addresses and
identity associations, was discussed and accepted by the WG.

The authors asked for help with temporary addresses.  Consensus from
WG was to proceed with as simple a mechanism as possible: addresses
are simply labelled as "temporary", with no additional statement in
DHCP spec about lifetimes, extending lifetimes, etc.; client can
request temporary addresses; server can assign temporary addresses.

Reconfigure now has a problem because of Inform message: currently,
only a Request can satisfy an outstanding Reconfigure message from the
server.  Inform should also satisfy Reconfigure.  Lemon pointed out
that Inform can satisfy Reconfigure only if server hasn't assigned any
addresses to the client; authors will revise text to reflect this
observation.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Steve Gonczi" <[email-masked]>
Date: Mon, 7 Jan 2002 14:57:53 -0500

Greetings,

I have just read the minutes of the last WG meeting. I am responding
to the following:

> (Tom) Narten said that
>recovery mechanism in response to a server failure. 

I believe RFC 3074 provides an option to deal with this...
Section 5.3 (Delayed Service parameter)

Happy New Year to all!

/sG

---

From: Thomas Narten <[email-masked]>
Date: Mon, 07 Jan 2002 16:33:05 -0500

> Section 5.3 (Delayed Service parameter)

But it is not required so you end up with different products doing
different things...

Thomas

---

From: "Steve Gonczi" <[email-masked]>
Date: Mon, 7 Jan 2002 17:59:47 -0500

I see your point.

As I recall it did not seem reasonable to mandate 
site admin policy. There was a discussion on the WG list
at the time, and we ended up making the _presence_ of this
knob optional.

Perhaps, we should mandate the _support_ of this option
in implementations, and just allow it to be turned off.

/sG

---

From: Thomas Narten <[email-masked]>
Date: Mon, 07 Jan 2002 21:15:49 -0500

> at the time, and we ended up making the _presence_ of this

Right. If the implementation is optional, the operator may not have
the option to enable, i.e., if the products didn't implement the
feature.

> in implementations, and just allow it to be turned off.

That might have been better. And would it have caused a lot of
hardship to implement?

Thomas