IETF 81 dhcwg meeting minutes
=========================
CHAIRS:
John Jason Brzozowski, Comcast (john_brzozowski@cable.comcast.com)
Ted Lemon, Nominum (ted.Lemon@nominum.com)

MINUTES:
Jason Weil

JABBER:
?

ADMINISTRIVIA:
draft-ietf-dhc-subnet-alloc - submitted to IESG, waiting on revised draft
draft-ietf-dhc-duid-uuid - in RFC Editor queue as of IETF81
draft-ietf-dhc-dhcpv6-relay-supplied-options - awaiting another pass through IESG
draft-ietf-dhc-dhcpv6-redundancy-consider -  intention is to public draft as an RFC, T. Mrugalski (co-author) to drive this process
draft-ietf-dhc-forcerenew-nonce - in WGLC
draft-ietf-dhc-l2ra - review required, chairs to send mail to WG
draft-ietf-dhc-relay-id-suboption - went through WG LC, IESG stalled for 2 years, author no longer working on this project.  Needs to go back to WG to discuss. If there is interest from the dhcwg we need for someone to pick this work up. 
dhc-dhcpv6-reconfigure-rebind - draft is currently expired, this work could be of possible use related to DHCPv6 failover.  S.Jian (Huawei) cannot work on this draft, nor is the original author (R.Droms).  Chairs will attempt to find an author to pick up the work and help refresh the draft if there is interest.
dhc-host-gen-id - need to determine level of interest for this draft, reached out to CSI chairs to determine if there is interest in CSI for this work.  To date confirmed there has not been.  Need to follow up with authors to determine next steps. 
dhc-cga-config-dhcpv6 - needs significant work before going to LC, reached out to CSI chairs to determine if there is interest in CSI for this work.  To date confirmed there has not been.  Need to follow up with authors to determine next steps. 


PRESENTATIONS:

dhc-options-guidelines-06 (David Hankins, Google)
-Draft has been expired
-IETF78 was planned for Last Call
-Chairs and WG agree the works is worth resurrecting and moving forward, will likely require an additional author
-S.Jian (?) (confirm spelling and last name) agreed to review, target date Aug 9th

dhc-dhcpinform-clarify-05 (David Hankins, Google)
-DHCPv4 related draft
-Seeking a contact at Microsoft to solicit feedback and facilitate adoption
-Microsoft client in particular sends a bunch of informs, until it receives a 252 reply.
-Microsoft .Net clients use local broadcast to respond, ideally clients clients should not to send zeroed ciaddr, this will go away with IPv6 adoption.
-Implementor should and would like to know what to do other than send unicast
-The standard must describe actual behavior of DHCP servers as well
-ciaddr behavior should not be omitted and recommend nobody else do that either, the open ciaddr issues are gating the progress of this document
-Review of this document will be requested on the mailing list in order for this to go to WGLC

draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (Hui Deng, China Mobile/Ted Lemon, Nomimum)
-Draft requires additional review and updating
-Updates include relaxation of limit on option 82
-Also adding a new option-like 83
-Support for legacy and layer 2 relay agents
-Question posed to the WG: should look at IP TTL when creating RELAYFORWARD or RELAYREPLY message?
-D.Hankins suggest adding  hop count instead to UDP payload, or limit the number of nested encapsulation layers
-This work is a an extension to DHCPv4 extension so needs to go now or never
-There was tentative interested expressed by a few during the WG meeting

draft-xu-dhc-cadhcp-00 (Cui Yang, Huawei)
-Questions raised regarding limitation of certificates?
-MTU limit of 1500bytes, certificate is 1-2k bytes
-Broadcast can't be fragmented
-Conclusion as not workable
-Proposed solution is for DHCP server establishes secure tunnel to trust server with certificate authentication option instead
-Comment from F.Dupont since there is no address and no connectivity, it is too early in process to worry about authentication, use SEND instead. This is client problem.  F.Dupont recommended the review of SEND since this is a similar issue.
-Indications are that the authors should share deployment experiences with the dhcwg
-T.Lemon described as helping against DoS attack, presenter claims that DHCP server has been attacked using this vector and that this work would help address the described issue.
-Comment from D.Hankins indicates that this has very limited usefulness due to requirement for pre-storing the certificates and that support for fragmented packets should be discouraged.
-T.Lemon to send mail to the WG mailing list to request more discussion and substantiate the practicality of this work.

draft-bi-dhc-opextensions-00 (Cui Yang, Huawei)
-This work is oriented around the need for DHCP clients and security configuration which needs to be configured by server
-RFC2132 does not provide a mechanism to address this need
-Works defines DHCP Security Specific option which includes Security-GW ID
-Comment by T.Lemon recommends splitting security option into separate draft and the security considerations needs more work

draft-jiang-6man-addr-registration-req-02 (Sheng Jiang, Huawei)
-The works defines requirements for the registration of host generated addresses
-Specifies the use of ND Address Registration Solicitation
-Open question regarding this work, should the new ND option carry IPv6 address of the default address registration server? Or use DHCPv6 discovery mechanism?
-Comment from the WG suggests that this option already exists
-Question from the WG, should we give different reasons for differing failure scenarios?
-Comment from T.Lemon the ability of the DHCP server to reject an auto-configured address is controversial
-Presenter provides an example, should reject if host generates IID incorrectly.
-Question from Alex (lastname?) this is a novel idea, would like to know if there IPR?
-Comment from T.Lemon this functionality already exists so not new
-Comment from G.Chen from an operators point of view this work would be very useful.
-Additional mailing list discussion is required
 
draft-ietf-dhc-secure-dhcpv6-03 (Sheng Jiang, Huawei)
-Security considerations added to the document
-CGAs of DHCPv6 servers may be pre-notified to hosts
-Author/presenter is requesting WGLC
-Comment from T.Lemon about inadequate level of review and comment
-No objection to WGLC during the WG meeting, will send WGLC request to the mailing list
-Support during the WG meeting for WGLC by those who read the draft.

draft-mrugalski-dhc-dhcpv6-failover-requirements-00 (Tomasz Mrugalski, ISC)
-This document defines the requirements (preparation work) for a DHCPv6 failover protocol, protocol development will follow requirements definition.
-Semi-redundant approaches for DHCPv6 are already documented (draft-ietf-dhc-dhcpv6-redundancy-consider)
-DHCPv4 failover failed to reach RFC, huge 130+ pages, DHCPv4 failover is current a BCP along with requirements and protocol specification all in one, no way to review.  The work took place over a 7 period of time. The goal is to avoid this with DHCPv6.
-Plan overview for DHCPv6 failover is step 0 Redundancy, step 1 documented requirements, step 2 design documentation, and finally step 3 protocol specification which will be a standards track document. 
-Current state of the work includes approximately 20 volunteers, 10 contributors.
-The team generally meetings weekly via conference calls, notify Tomasz if interested in participating in meetings
-Overview of what the requirements document includes:
--1-1 Pair
--PD MUST be supported
--Prefix/add pool MUST NOT participated in more than one relationship
--Healthy server MUST continue serving leases of failed partner
--Failover MUST NOT introduce per penalty
-WGLC has been requested redundancy considerations document which is informational
-Request has been made to accept DHCPv6 failover requirements document as a WG work item (requesting WG adoption)
-Comment from M.Lampo regarding concern for primary role for server vs network
-S.Jian (Huawei) expressed concern regarding the size of the requirements document (20+ pages), failover scenarios reference section takes up majority of draft
-T.Lemon indicated that remarks regarding the size of the draft are more useful after the document has become a WG item

draft-ietf-mif-dhcpv6-route-option-01 (Tomasz Mrugalski, ISC)
-Draft originates from the MIF WG, requesting dhcwg review
-Work could be used for generic routing configuration mechanism including use with 3GPP
-Document specifies a DHCPv6 IA_RD Option, one or more IA_NEXT_HOP options, and one or more IA_RT_PREFIX
-Document has generated a considerable interest from enterprise community
-The discussion around DHCPv6 vs RA has been around for some time
-Benefits that have been discussed include:
--specify routing on a per host basis
--speed up configuration
-Unresolved concern with Routing Area Director remain outstanding
-A.Petescu comments that he doesn't believe fields could be extended, could say this draft does not do default route
-D.Hankins commented regarding IA_IDs, specifics unavailabile
-A.Petescu, J.Brzozowski, S.Jian offered to review draft

draft-cui-softwire-dhcp-over-tunnel-01
-Original Use Case for the document was 4over6 (draft-cui-softwire-host-4over6)
-Also assumes no NAT on AFTR and moves NAT to B4
-A Client Relay Agent sits on client machine and listens on IPv4 port 67 and forwards packet over UDPv6 with option 82 allowing for DHCPv4 over IPv6 transport
-This document was submitted to the dhcwg per AD requested
-General sense during the IETF81 dhcwg meeting is that this is a good idea, there were no objections
-Further there were no objections to accepting this as a WG work item
-Question from R.Droms has this general topic come up before?  T.Lemon indicated that this has come up in a different context in that it typically is how to you support DHCPv4 over tunnels not DHCPv4 over IPv6.  This seems like a good solution for the problem.

draft-mrugalski-dhc-dhcpv6-4rd-00 (Tomasz Mrugalski, ISC)
-Author requesting a review of this document at this time
-The document defines the requirements for 4rd
-4rd requires 1 anycast BR IPv6 address and one or more 4rd mapping rules
-Question raised, is an Internet Draft required to define the mapping rules?
-Volunteers for this work include D.Hankins, S.Jian
-S.Jian will volunteer after adoption by softwires WG
-Wait for voluteers until after softwires reviews

draft-mrugalski-dhc-dhcpv6-suboptions-01  (Tomasz Mrugalski, ISC)
-This draft documents how client request sub-options
-Comments include:
-J.Brzozowski indicates there are similar issues with DOCSIS
-D.Hankins prefers a 2nd option which includes ORO in each requested scope
-T.Lemon prefers 1st option which inched option on any scope
-Some folks in at the dhcwg meeting were in favor of adopting this document as a WG work item
-J.Korhonen (Nokia) inquired if this would this affect his draft which is in WGLC?
-R.Droms indicated that there would be no impact

draft-yeh-dhc-dhcpv6-prefix-pool-opt-04 (L.Yeh, Huawei)
-AD A.Ferrel supports idea of using DHCPv6 to update routing table on edge router
-There was a call to request the adoption of this document as WG item
-Alexandru (lastname?) indicated a need for this option
-R.Asati expressed that he felt this is a bad idea and that this work belongs in aggregation at routing space
-T.Lemon inquired of this is scope for the dhcwg and asked if there are any competing proposals?

draft-ietf-dhc-pd-exclude-02 (J.Korhonen, Nokia)
-WGLC 

draft-ietf-6man-addr-select-opt-01 (Tim Chown, University of Southampton)
-This document is being worked alongside RFC3484bis
-It documents a mechanism to update default policy table
-Author/presenter asked is asking if this ok to the dhcwg, requesting review?
-Chairs will request dhcwg review, J.Korhonen volunteered to review