Subject: [dhcwg] Minutes from IETF74 dhc meeting...

From: Ted Lemon <[email-masked]>
Date: Fri, 8 May 2009 09:25:38 -0700

We're running a little late in submitting the meeting minutes.   I've  
included the preliminary version of the minutes below.   We're going  
to submit this as final later on today; if you have any additions or  
corrections, please get them to us today.

I'd particularly like to call your attention to the discussion of  
draft-huang-dhcp-su-00 down at the bottom where I think I remember a  
comment that wasn't in the notes.

Thanks!

Minutes for the DHC WG Meeting @ IETF 74
1300-1500 PDT 2009-03-25

Thanks to Suresh Krishnan for taking notes.  These minutes were
prepared by the WG co-chairs: John Brzozowski and Ted Lemon.

Initial announcements
------------------------------------------------------------------------

Agenda is very agressive.  Drafts ready for WGLC will present only 1
slide.

Ralph has been chosen to become the new Internet AD. The WG is looking
for a replacement chair.  Ralph will continue working with the WG as
the AD and IESG advisor

Today is the 20th anniversary of the first meeting of the dhc WG.  It
has been a great example of collaboration between competing vendors.

Ralph went through the WG document status and solicited more reviews
for documents in or approaching working group last call.

Richard Johnson presented Bulk Leasequery
draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt
------------------------------------------------------------------------

Two independent drafts were written that described methods for doing
bulk leasequery. They have been merged into one.  Extensive editorial
changes have been made to the draft and some changes to make it more
palatable to the IESG.

Ralph asked for more people to review the document.

** David Miles volunteered to review the document

David Hankins presenting Softwire Tunnel Option
draft-dhankins-softwire-tunnel-option-02.txt
------------------------------------------------------------------------

No major changes.There are some scenarios that require further  
discussion
in the softwire wg.

** Document will be progressed in softwire.

David Hankins presenting Option Guidelines
draft-ietf-dhc-option-guidelines-05.txt
------------------------------------------------------------------------

Extensive editorial changes for readability and usability. Specifies
guidelinesfor people trying to design new DHCP options. Not enough
people in the room have read the document.

** Suresh Krishnan, Ted Lemon and Richard Johnson will review the
document in working group last call.

David Hankins presenting DHCP Inform Clarify
draft-ietf-dhc-dhcpinform-clarify-03.txt
------------------------------------------------------------------------

Subnet selection option completely removed from server evaluation after
discussion with Bernie Volz. This document explicitly acknowledges
the fact that DHCPINFORM is not just for manually configured hosts.
and documents the "de facto" standard of clients that zero
htype/chaddr/ciaddr. New text added to security section on use of this
mechanism as an amplification vector.

Ted wants to know if it would be interesting for the server to respond
to the source port of the packet and David H agrees. Not many people
have read this document.

** Chairs to nag more people into reading the document.

Frank Xia presenting Host Generated IIDs
draft-xia-dhc-host-gen-id-01.txt
------------------------------------------------------------------------

Ted wants to know if the client can generate the iid first and put it  
in the
SOLICIT.

Suresh Krishnan thinks that this is not possible since the prefix  
feeds into
the generation of the interface identifier part of a CGA.

David H explains a different mechanism for doing this: Solicit prefix,
generate another address and suggest this in an IA option.

David Miles is worried about the applicability statement that does not
restrict to CGAs

Frank talks about using this for point-to-point links as well.

Frank wants adoption as wg item.

Ralph thinks that it is premature to even ask the question since it is
not clear whether dhc or csi should take this up.

Jean Michel Combes wants to know if DHCP-PD can be used in this case.

Ted and Ralph think it cannot be used.

Jari Arkko thinks something like this is needed. He thinks that it
also needs to be able to work with Router Advertisements in addition
to the default router and prefix options specified in Default Router
and Prefix Advertisement Options for DHCPv6
(draft-droms-dhc-dhcpv6-default-router-00.txt)

Vincent Zimmer presenting DHCPv6 Option for Network Boot
draft-ietf-dhc-dhcpv6-opt-netboot-03.txt
------------------------------------------------------------------------

This document is the merge of two drafts. Provides a network boot
mechanism for DHCPv6 that has existed for a long time in DHCPv4.

Mark Millet wants to know if https is supported in the URL. Vincent says
yes.

David H. wants to know if it is better to just send out a config file  
that
lists and describes bootable files. He also wants to know how access  
control is
performed. How is the initrd sent over?

Vince has not thought about these yet and they are not handled in the
current draft.

Ted L wants to strongly recommended http in the document.

Vincent agrees.

Rob Austein thinks [in response to Dave Hankins' comment] that what
goes on between the provider of the boot service and the boot loader
is highly variable and the wg should not define what the URL means.

Mark Millet wants to know if there would be a length limit on the URL

Vincent will add it in a later revision.

** Document will be adopted as wg item pending confirmation on the
mailing list.

Evan Hunt presenting DHCPv6 MRC Clarification
draft-hunt-dhcpv6-clarify-mrc-00.txt
------------------------------------------------------------------------

Minor clarification of the Maximum Retransmission Count defined in  
RFC3315.
This was causing some issues in compliance tests like TAHI.

Jinmei Tatuya wants to know if it is time to start revising RFC3315  
since
there are a lot of clarifications.

David wants to progress the draft as is instead of including it in the
errata

** Document will be adopted as wg item pending confirmation on the
mailing list.

David Miles presenting Forcerenew Key Authentication
draft-miles-dhc-forcerenew-key-01.txt
------------------------------------------------------------------------

Tries to bring similar functionality into DHCPv4 as exists in DHCPv6.
Distributes a forcerenew key to the client in initial dhcp exchange for
subsequent use.

Francis mentions that the DHCPv6 mechanism referenced this document is
well known to be supported by nobody in DHCPv6.

David M mentions that there is demand from some operators (he names 2).

Glen Zorn wants to rename the key to be called a nonce since it is not
really a key  He also does not see this document as providing any  
security.

Ted Lemon clarifies this only protects against off-link attackers.

Glen Zorn wants some text in the security considerations to mention  
this.

** Document will be adopted as wg item pending confirmation on the
mailing list.

David Miles presenting L2RA (DHCPv4) and LDRA (DHCPv6)
draft-ietf-dhc-l2ra-03.txt
draft-miles-dhc-dhcpv6-ldra-02.txt
------------------------------------------------------------------------

The main intent of both drafts is to insert relay agent options on
non-routing devices without any IP configuration.

David Hankins wants to know if link local addresses could work, and
David Miles clarifies that the goal is to have no IP addresses at all
on the relays.

Jinmei wants to know if the wg agreed whether layer violating devices
like these were a good thing.

Ralph mentions that the wg only acknowledges the existence of these
devices without taking a position on whether they are good or not.

David Miles says L2RA is already implemented and deployed.

LDRA does not exist yet and can be tailored appropriately.

Woj wants to know why the L2RA needs to check for the relay agent
information option

David H clarifies that the Relay Agent Info option was defined long
ago in RFC3046 and not by this draft.

Woj wants to know if L2RA needs to define an option to identify the
relay agent?

Discussion will be taken to the mailing list.

Ralph wants to co-ordinate these two drafts so that they solve the
exact same problem and the L2RA draft accurately describes the
existing implementations

** The LDRA draft will be adopted as wg item pending confirmation on the
mailing list.

Woj presenting DHCPv6 route option
draft-dec-dhcpv6-route-option-01.txt
------------------------------------------------------------------------

This mechanism is needed by broadband operators to provision static
routes on Residential Gateways and CPEs.

Francis wants to ensure that complete prefixes are sent in the routes
without any compression.

Alan Kavanagh mentions that there are no known Broadband (DSL)
Residential gateways that have multiple uplinks, and Woj agrees.

Alan also wants to know if this is applicable only to shared (n:1)
vlan scenarios and Woj says no.

Alan thinks that RIPng or OSPF would be a better solution for this.

Woj says that the base assumption is that IGPs are not being used.

Erik Nordmark mentions that this is going down the road of conflicting
with RAs. He also thinks that this should use the same format and the
semantics as the RA options for prefixes and routes. He thinks that
there should be a shared container option for carrying RA options over
DHCPv6.

Ralph disagrees with Erik and wants to specify each option separately

Erik thinks conflicting info is hard enough to merge and conflicting
formats could make it harder

Sanjay Wadhwa is not clear how downstream routing (NAS->RG) works
with this option. This will be discussed offline.

David H disagrees with Erik since there is also manual configuration
is in play. He does not want DHCP specified info to be merged with the
manual configuration.

Dave Thaler completely agrees with Erik.

Ralph has talked about this issue at the routing area meeting and he
would like this draft to be evaluated with those criteria.

** Ralph thinks that the draft is not ready for adoption as a WG item.

David Hankins wants to talk about the default router option and Ralph
wants to leave it till the end.

Ralph Droms - DHCPv6 RAAN Option and SRSN Option
draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt
draft-ietf-dhc-dhcpv6-srsn-option-02.txt
------------------------------------------------------------------------

This draft discusses how an edge router acting as a relay agent can
learn the prefix delegated to a home gateway.

Ted Lemon mentions that the information in the relay part will always
match the information in the client part.

Ralph thinks it is possible that it would be different and explains
how the lifetime sent to the relay agent could be longer than that
sent to the client in order to prevent route flaps near the time of
expiry of the address.

Jason thinks that this wg needs to at least provide guidance on what
the implementations need to do to solve this problem.

Ted thinks that is fine but he does not agree in duplicating
information in both the relay and client messages. He wants to discuss
use cases first before going any further

David H mentions that DHCPv6 does not provide a way to talk to a relay
agent in a reliable fashion. He does not think that srsn is the right
way to do so.

Frank Xia wants to know if the HG and the ER need to run IGP.

Ralph says no, they do not run IGP between each other.

David M thinks this comes too late and vendors are already snooping
the packets to infer the prefix.

Mark Andrews mentions that in some cases it may make sense for the
DHCP server to provide a wider prefix to the relay agent than to the
router in order to optimize the routing table.

* NO DECISION

Hui Deng presenting Extension of DHCP Relay Agent Information Option
draft-huang-dhcp-su-00
------------------------------------------------------------------------

This draft allows multiple relay agents to add information to the
message so that the server can infer the path of the message.

Ted Lemon mentions that this functionality originally existed before
RFC3046 and he thinks that the right way to solve this is to add
multiple relay agent options to the message instead of appending to
existing option.

David H is not sure if implementations follow option concatenation
properly.

Ted thinks this option is handled completely differently from any
other options and everything should be fine unless the option ends up
being very long.

[I seem to recall someone saying they knew of implementations that
would fail if multiple relay agent information options appeared in the
same packet. --Ted]

* NO DECISION

Glen Zorn presenting DHCP Authentication
draft-pruss-dhcp-auth-dsl-04.txt
------------------------------------------------------------------------

The analysis draft regarding DHCP authentication has been posted
today.

Jari wants to know if the draft is ready for the working group to make
a decision or if there are still open issues as identified by the
analysis draft.

Jason mentions that one more round of revisions is probably required
to address this analysis.

The latest version of the draft has been rewritten to use vendor
specific options.

Richard Johnson has made changes to the DHCP server on IOS to support
this and he also has an open source linux client implementation.

Frank Xia has an alternate solution and he would like this to be
considered.

* NO DECISION
<OUT OF TIME>