[dhcwg] Minutes fro IETF 68 dhc WG meeting

[Ralph Droms <[e-mail]>]

We've submitted the WG minutes, which are available at
http://www3.ietf.org/proceedings/07mar/minutes/dhc.txt and are copied below.

The minutes can be revised within the next few days.  Please review the
minutes and respond to the chairs or to the dhc WG mailing list with
additions, corrections or other comments.

- Stig and Ralph
  dhc WG chairs

=====

                           DHC WG - IETF 67
                      0900-1130 2007-03-21 (Wed)
                           MEETING MINUTES
                      --------------------------

The chairs appreciate the minutes taken by Shane Kerr and the jabber
scribe, Mark Andrews.  These minutes are based on their input.

Administrivia
  The chairs opened the meeting with agenda bashing, circulation of
  blue sheets and identification of scribes.


Draft last call and adoption announcements

  The chairs gave a status update on WG documents and work items.

* Submitted to IESG
  draft-ietf-dhc-server-override
  draft-ietf-dhc-relay-agent-flags
  draft-ietf-dhc-dhcpv6-opt-dnsdomain
  draft-ietf-dhc-dhcvp6-leasequery
* In or through WG last call
  draft-ietf-dhc-dhcpv6-ero (ready to submit to IESG)
  draft-ietf-dhc-dhcpv6-reconfigure-rebind (revision required)
    Authors to submit revision based on last call comments; then
    requires new WG last call
  draft-ietf-dhc-subnet-alloc (insufficient response)
    Need to determine WG consensus for standards track or
    informational; then requires new WG last call
* Ready for WG last call
  draft-ietf-dhc-pxelinux (will start WG last call next week)
  draft-ietf-dhc-vpn-option (pending review of final comments)


Reclassifying DHCPv4 Options - RFC 3942
  Bernie Volz gave an update on the process to reclassify DHCPv4
  options as specified in RFC 3942.  In May, 2006, IANA moved all
  options that were not announced as "in use" to "Available".  Reports
  were received on the following option codes:

  128-135: PXE (only formal submission received; other uses reported
           anecdotally)
  150:     TFTP server addresses documented in
           draft-raj-dhc-tftp-addr-option; no documents received for
           two other reported uses
  175-177: Uses reported but no documents received
  208-211: PXELinux options; documented in draft-ietf-dhc-pxelinux
  220:     Subnet allocation; documented in
           draft-ietf-dhc-subnet-alloc
  221:     Subnet selection; documented in draft-ietf-dhc-agent-vpn-id

  Bernie proposed assigning option codes 128-135, 150, 208-211 and
  220-221 as "Tentatively Assigned", and reclassifying 175-177 as
  ""Available".  Bernie will write an I-D summarizing progress on RFC
  3942 progress for WG review and approval before requesting the
  changes from IANA.

Report from DHCPv6 interoperability test event
  Alain Durand reported on an interoperability test event sponsored by
  Comcast, which was held the week before the IETF meeting.  The
  primary objectives were to test interoperability and test some
  specific deployment scenarios.  Participating were: 7 vendors, 14
  participants (one remote), 13 implementations (5 clients, 5 servers,
  3 relays).

  Alain will publish an I-D with a summary of the test results
  (subject to NDA constraints).  The WG chairs will set up issues
  tracker for issues identified in Alain's I-D

DHCPv6 RAAN Option, draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt
  Work on the DOCSIS 3.0 specification revealed a problem with DHCPv6
  prefix delegation: if the PD delegating router is not on the same
  link as the requesting router (implying a relay agent), how can
  routes to the delegated prefix be injected into the routing
  infrastructure.  Bernie Volz described the DHCPv6 RAAN option, which
  allows the DHCP server to inform the router (which provides the
  relay agent function) on the same link ("first hop router") with the
  requesting router about delegated prefixes; that router can then
  advertise the new prefix in the appropriate routing protocols.
  
  The WG discussed some of the requirements.  Bernie Volz pointed out
  that the first hop router needs information from both the server and
  from the requesting router (Release/Decline for the latter source).
  Ted Lemon suggested validating RAs from the requesting router;
  Ralph Droms responded that in some deployments the requesting
  routers will not be configured to issue RAs.  Alain Durand asked
  about recovery of state generated by the RAAN option; Bernie
  responded that state recovery is a separate issue, addressed, for
  example, by leasequery.

  The draft for this option did not pass dhc WG call.  Issues raised
  during the last call include:

  - Requires use of sequence numbering for reliability

  - Release/Decline Reply may be lost so relay agent may not get RAAN
    information and does not know to remove routes

    Ted said that the only case we are worried about losing data is
    Release/Decline, which could be solved by a new message from the
    server direct to the relay.  Ralph pointed out that Ted's
    suggestion would represent a new paradigm for DHCP communication:
    server to relay.  Ted said another advantage would be to obviate
    the need for message numbering to provide reliable delivery to the
    relay agent.

  - General dislike of idea of piggybacking

    Dave Hankins said he thinks there will be lots of use cases
    outside of this. The SRSN feels like a "slippery slope" in
    complexity. Bernie suggested that reliable server to relay
    reliable communication means the SRSN option is unnecessary.  Fred
    Templin said server-relay communication could solve the problem of
    clients that disappear and require state change in the relay
    agent.

  The chairs will start further discussion of requirements and
  solutions on dhc WG mailing list

Container Option for Server Configuration,
draft-droms-dhc-container-opt-00.txt
  Ralph Droms described a DHCP "container" option, through which a
  DHCP server can pass specific options to a DHCP server, for
  forwarding to specific clients.  The use case is STB CPEs in a
  subscriber network, which use the subscriber DHCP server.  The SP
  DHCP server may have some specific options, such as addresses of
  servers for the STB, that need to be delivered to the STB.  There
  was insufficient support to take on this proposal as a WG work item.
  Ralph will revise I-D based on mailing list discussion; WG to be
  asked to consider I-D as dhc WG work item

DHCPv6 Vendor-specific Message,
draft-volz-dhc-dhcpv6-vendor-message-00.txt
  Bernie Volz presented this proposal, which defines vendor-specific
  DHCP message codes, similar to vendor-specific options, for
  experimentation and development. Ted Lemon and Thomas Narten were
  opposed to the proposal as a mechanism for promoting
  non-interoperability.  Bernie responded that we've had trouble with
  open "site-specific" codes, and gave server-server protocols and the
  RAAN server-relay messages as use cases.  There was insufficient
  support to take on this proposal as a WG work item.  The WG chairs
  will start further discussion on dhc WG mailing list

Principles of Internet Host Configuration,
draft-aboba-ip-config-00.txt
  Dave Thaler gave an informational presentation about this draft; no
  action required by dhc WG.

Authentication Extensions for the DHCP,
draft-pruss-dhcp-auth-dsl-00.txt
  Ric Pruss presented this proposal as a way to use DHCP for user
  authentication.  The problem space is the transition by DSL
  providers from PPP to IP.  The PPP session semantics must be now
  provided as "IP session", but there is no single "IP session"
  protocol.

  Relay agent information option contents is sometimes used for this
  purpose today, but it is not always sufficient.

  Proposal option 1 uses no new DHCP messages but requires a second
  DHCPDISCOVER message (for a total of six messages).  Proposal option
  2 defines new DHCP messages that integrate authentication as a
  separate mechanism within the usual DHCP message exchange.

  Ted Lemon asked why RFC 3118 is not sufficient.  Ric responded that
  RFC 3118 requires pre-distribution of keys.  Ralph pointed out that,
  while draft-pruss-dhcp-auth-dsl uses pre-distributed subscriber
  passwords, those passwords are different from RFC 3118 keys and not
  immediately usable with RFC 3118.  Also, in the abstract, RFC 3118
  is a way of securing DHCP messages, not of authenticating user
  identity.

  Ted asked why the change to the state machine was necessary.  Ric
  replied that the user identity must be authenticated before an IP
  address can be assigned.  Also, there may be intermediate devices in
  the path which will learn the address and only activate it on
  DHCPACK.

  Hannes Tschoefinig said that inserting EAP into DHCP violates the
  EAP applicability statement.  Ted said that changing the DHCP state
  machine is hard and the 4-way handshake should be enough.

  Mark Townsley said that one goal is to authenticate the user
  identity before giving any information in a DHCPOFFER.  Ted asked if
  that information is sensitive?  Ric responded no, but its hard to
  predict how the user will be authenticated to give correct
  information.

  Ralph pointed out that this proposal is predicated on the assumption
  that user authentication should be accomplished in DHCP.  In fact,
  the user authentication architecture needs to be agreed upon first.
  If user authentication goes into DHCP, then the dhc WG can design
  the protocol to meet the architecture requirements.

  Jari Arkko said that the first step is agreeing that DHCP protocol
  is right place for this. That discussion needs more people than in
  this room, like DSL community. He will talk to chairs and post
  something on the list.

  Ric will get concrete requirements from DSL
  Forum.  The chairs will announce a discussion of the user
  authentication issues on the int-area mailing list.  The Internet
  ADs and the chairs will decide how to have the user authentication
  architecture discussion.



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