[dhcwg] Minutes from dhc WG meeting at IETF 63

[Ralph Droms <[e-mail]>]

Included below are draft minutes from the dhc WG meeting at IETF 63.
Please review and respond with additions/corrections before 1700EDT on
Aug 31.

- Ralph

=====

Administrivia from the chairs
-----------------------------

A revision of draft-ietf-geopriv-dhcp-civil-06 will be published soon
that gives details about "security concerns related to using DHCP to
update the database."  Members of the WG are asked to review the
changes in the new revision, relative to
draft-ietf-geopriv-dhcp-civil-04, which was reviewed in a dhc WG last
call.

The chairs asked for volunteers to restart two initiatives: DHCP
threat analysis, DHCP implementation experience.

The chairs are reviewing draft-ietf-dhc-failover-12.txt prior to
submission to the IESG.

The WG discussed the status of draft-ietf-dhc-bcmc-options-02.txt.
There are some IESG Discuss issues outstanding.  Ted Lemon said that
he had commented during the WG last call that he would prefer that the
BCMC option specify only IP addresses and not FQDNs.  Elwyn Davies
reviewed issues raised by the General Area review team.  Stig Venaas
will post a summary of outstanding issues to the WG mailing list.  The
authors will publish a revision that addresses the outstanding issues.


DHCP Option for Proxy Server Configuration
  <draft-ietf-dhc-proxyserver-opt-02.txt>
------------------------------------------

Michael Alexander presented and raised a couple of issues: use RDF or
XML encoding; push or pull Javascript?  Ted Lemon noted that XML
encoding may be too large to fit in a DHCP message.  David Hankins
said he is satisfied with the responses to his earlier comments about
the draft.  Mark Stapp asked if there are any expected uses of this
option.  Hankins respnded that the RedHat "network manager" would
likely use it.  The WG came to consensus use a URI that could be used
to obtain additional configuration information.  The authors will
revise the draft to specify the use of URIs.


Merging of data from DHCP4 and DHCPv6
  <draft-venaas-dhc-dual-stack-merge>
-------------------------------------

Stig Venaas presented and explained that this draft gives solutions to
some of the issues raised in draft-ietf-dhc-dual-stack-03.  Examples
of solutions include using FQDNs in options (returning both IPv4 and
IPv6 addresses) and depend on implementation of address selection
rules (RFC 3484) for selection between IPv4 and IPv6.  Alain Durand
noted that there is some urgency in coming to a solution, and that the
client's DUID might be useful to a merged DHCP server to correlate the
DHCPv4 and DHCPv6 clients from the same host.  Tim Chown responded
that a solution is needed quickly, but the WG must be sure to review
all possible solutions.  Another suggestion was to use IPv4-mapped
addresses in IPv6 options.  Ted Lemon said that the draft doesn't
actually say what's going on before talking about how to solve the
problem.  There was unanimous consensus at the WG meeting to accept
the draft as a WG work item.  WG consensus will be confirmed on the WG
mailing list.


DHCPv6 Default Address Selection Policy option
  <draft-fujisaki-dhc-addr-select-opt-00.txt>
----------------------------------------------

T. Fujisaki presented.  The WG discussed which WG should be
responsible for this draft.  Ted Lemon asked why we are waiting if we
are addressing control of a mechanism that is already specified in an
RFC?  Margaret Wasserman said there needs to be a demonstrated
requirement, and the option should be developed with those
requirements in mind.  The ipv6 WG discussed RFC 3484; specifically,
should RFC 3484 be revised because some text is obsolete (e.g., text
referring to site-local addresses) and is the address selection
mechanism is useful.  There are some scenarios in which centralized
control of address selection would be useful: if RFC 3484bis defaults
are not appropriate; shim6 WG would find centralized control useful.
Greg Daley suggested the selection mechanism could also be controlled
through router advertiesements.  The dhc WG decided to defer
consideration of the draft until the ipv6 WG decides (a) what to do
about RFC 3484; (b) is centralized control of address selection useful
and (c) should it be controlled through a DHCP option.


Zone Suffix Option for DHCPv6
  <draft-yan-dhc-dhcpv6-opt-dnszone-02.txt>
-------------------------------------------

R. Yan presented.  This option addresses the deployment scenario in
which hosts need to learn about domain suffix (not "zone suffix") in a
network that has acquired IPv6 addresses through prefix delegation.
Ted Lemon asked that text restricted use to a particular deployment
scenario be deleted, as the option may have broader application.
There was consensus at the WG meeting to accept the draft as a WG work
item.  WG consensus will be confirmed on the WG mailing list.


DHCP Option for CLF/NASS
  <draft-lijun-dhc-clf-nass-option-00.txt>
------------------------------------------

Spencer Dawkins presented.  This option addresses configuration of
NGN terminals (TE) with a network identifer.  The identifier may be an
IPv4 address, an FQDN or a string (for networks that don't tie
identification to IP).  Dawkins said that there is no need for an IPv6
encoding today. Ted Lemon said the draft uses many undefined
acronyms.

The WG then discussed the problem of data encoding in DHCP options.
Various DHCP server implementers came to consensus that representing
different data encodings as sub-options would be the easiest to
implement.

There was insufficient WG review and response to take the draft on as
a WG work item.  The WG will review the next revision and reconsider
its status.


TAHI DHCPv6 test tool
---------------------

Nobumichi Ozoe presented.  TAHI expects to have a beta release of
DHCPv6 test tools available October 2005, and 1.0 release April 2006.
Announcements of availability will be posted to the [e-mail]
mailing list.  Also watch www.tahi.org/dhcpv6.


DHCPv6 client
-------------

Ted Lemon announced that he has been developing a DHCPv6 client based
on the ISC DHCPv4 client.  The protocol work is done and he is now
working on stack integration.  Rob Austein said that ISC is interested
in the client.


Status report on option code registration
-----------------------------------------

Bernie Volz reported on option code registration as specified by RFC
3942.  He has discovered many clashes; details available at iana.org.
18 options have been described as "tentatively assigned" in 128-223
space; 10 of those options have multiple uses.  The good news is that
78 out of the possible 96 option codes have not been claimed and are
available for assignment to new DHCP options.  Those claiming usage of
options will be asked to document that usage in an Informational RFC.

DHCPv4 option for PANA Authentication Agents
  <draft-suraj-dhcpv4-paa-option-00.txt>
----------------------------------------

Suraj Kumar presented.  Mark Stapp pointed out that this option also
uses multiple encodings (see earlier discussion) and should be
redefined to use sub-options.  Greg daley noted that the DNS name
might not be useful because a host cannot use DNS if it is not
authenticated.  There was unanimous consensus at the WG meeting to
accept the draft as a WG work item.  WG consensus will be confirmed on
the WG mailing list.


Review of RA M/O bits discussion
--------------------------------
S. D. Park presented a summary of the discussion about the ND RA M/O
bits that has been on the ipv6 mailing list and at the ipv6 WG meeting
at IETF 63.  The ipv6 WG has three requirements (from
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05255.html): 

1) Ability to indicate to a host "DHCP is not available on this link",
   with the expectation that the host won't send any DHCP messages

2) Ability for a host to get all desired and available DHCP
   configuration with a single DHCP message exchange

3) Ability to do DHCP without having to configure routers
  (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or
  ICB anyway)

Requirement 1 is acceptable, the dhc WG will need to investigate
requirement 2 and requirement 3 is not suitable.  Mark Stapp pointed
out that the use of the M/O bits should be to indicate availability of
a service.


DHCPv6<->DNA interaction
------------------------

Brett Pentland presented work from the dna WG that may have an impact
on DHCPv6.  DNA would eliminate the need for DHCPv6 Confirm/Reply
message exchange (which is itself a form of "DNA").  There will be a
discussion on the dhc WG mailing list about whether DNA would require
a chnage to RFC 3315.


Route Injection for DHCPv6 Prefix Delegation
--------------------------------------------

Ralph Droms summarized a discussion about injecting routes for
delegated prefixes when the delegating router (DR) and requesting
router (RR) are not on the same link.  Alternatives:

1. RR injects the route (generic routing protocol)
2. Relay agent injects the route
2a. Relay agent learns about delegated prefix through relay agent
    option 
2b. Relay agent learns about delegated prefix by snooping messages to
    clients
2c. Network element on which relay agent resides (that must perofrm
    route injection) learns about route through some out-of-band
    mechanism (some other configuration protocol)
3. DR (really, DHCPv6 server) injects the route

Option 1 involves trusting the RR: authenticate its identity,
authenticate the contents of the update message, confirm the RR has
the right to advertise the prefix.  Options 2 require something like
leasequery so the relay agent cna recover state.  Option 3 is probably
not viable.  The WG will continue discussion on the mailing list.



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