Minutes for DHC at IETF-90
minutes-90-dhc-1

DHC Working Group Minutes

Last edit: 08/15/2014 10:40 EDT

DHC WG meeting started at 9am, Saloon room B, Wed 23 July 2014, Toronto.

Bluesheets - 20+24 = 44 attendees


*** Working Group Administrativia
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-0.pdf)

Andrew Yourtchenko volunteered as jabber scribe. Thanks!

Sheng Jiang has been assigned as DHC secretary. He will take minutes, too.

WG Update:
- CER document will be handled by Homenet, not DHC.
- DHCPv6 router options document is not for DHC WG; notify authors. Probably
  needs to be 6man or similar (they should discuss with ADs).
- Captive Portal ID in DHCP/RA - Not DHC WG document; notify authors. See above.
- Sheng's stateful reconfigure is "dead for now".
Sheng: we haven't found solid use case of Stateless Reconfiguration

Sheng: more reviews on address registration draft would be helpful. Authors
solved all comments received. WG should go second WGLC later.

Bernie Volz: WG is going through a minor recharter

Ian Farrer: introduce Yang Model for DHCPv6 client


*** DHCPv6bis Update
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-7.ppt)

Tomek: report on 3315bis work

Ted Lemon: should adopt first, and then require consensus process work

Bernie: the authors would like to get consensus internally in the group and
address all known issues before adopt, then people can review a complete
version during adoption call

Tomek talking about the server may ignore the hint from client
	- Client & server policy - client should be able to operate with hint
	  length that doesn't match PD.
	- Don't ignore everything else
	- Graceful renumber (renew with existing but request hint, which
	  server could honor).

Ole Troan: prefix length as a hint should also be able to be ignored

Tomek: it is not intended that server must accept what the client requested,
might need some rewording.

Ted: should split the cases

Bernie: client should be survive if it does not get what the hint required,
would make this clear in the document

Suresh Krishnan: it may be out of scope. The client implementation could be:
give me what I want or nothing.
Bernie: in general clients should accommodate what are form operators

Ted: provide another scenario (maybe a separated draft)

Lorenzo Colitti: how this hint relevant to SLAAC should also be considered

Michael Abrahamsson: a use case for client-initiated renumbering, e.g.
customers don't want the current assigned prefix, and to get a new one
through some mechanism

Bernie: it is not clear how the hint should be handled generally

Ole: is it ok to ask container option without suboptions?

Tomek: yes

Tomek talking about the Client Rate Limiting issue

Sheng: server should also be able to limit the request rate from the same
client

Tomek talking about filling link-address

Ted: more detail should be given why and how to do it, may be a separated
document

Bernie: just a recommendation that basically you should use a Global or
Unique Local address for relay

Fred Templin: give an example

Bernie: Link-addr SHOULD not be the link-local address

Tomek talking about "confirm no longer mandatory"

Bernie, Ted: it should be a "SHOULD"


*** DHCPv6 Stateful Issues
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-2.pdf)

Bernie talking about stateful issues

Sheng: update to 3315 and 3363 should also be in 3315bis

Bernie: has not been included in 3315bis, until WGLC

Tim Winters: there are clients that actually doesn't accept top-level status,
but they do handle status in IA_NAs.

Reviewers Fred Templin, Leaf Yeh, Francis Dupont, Jason Weil, Ian Farrer,
Andrew Yourtchenko, Qi Sun, Cong Liu


*** Secure DHCPv6
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-1.pdf)

Dacheng Zhang talking about Secure DHCPv6 with public key

Daniel: add trust anchor is not that difficult, leap of Faith is enough to
make sure client connect to the same server

Lorenzo: not sure what the threat model is, if there is strong L2 security,
might not need this

Maraus: prefer option 4 (drop certificate from this draft totally)

Daniel: it is useful for client to authorize server

Ted: server authorize client is also useful, though not very clear

Lorenzo: l2 security may be enough and better

Ted: client authorize server is more useful. Secure DHCPv6 regardless
server or client is good

Francis: URL for certificate may be help

Lorenzo: should get data to continue this work

Bernie: at least one use case that the client authenticates the server

Suresh: how to prove a DHCP server out of leap of faith

Ted: the point is to talk to the same server that the client has talked before

Maraus: support

Suresh: Leap of faith make sense, others don't

Bernie: the authors could summarize the discussion and come back to mail list
for WG consensus


*** DHCP Configuration based on Network Topology
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-8.pptx)

Tomek presenting Customizing DHCP Configuration On the basis of Network
Topology

Suresh: ask a question regarding to normative reference, DHCP base reference
was moved to informative, it should remain normative

Bernie: Add DHCP RFCs back as normative references/not informative

The feeling in the room is that the draft is ready for WGLC


*** Dynamic Allocation of Shared IPv4 Addresses
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-5.pptx)

Qi Sun talking about Dynamic Allocation of Shared IPv4 Addresses

Ted: is this required for lightweight 4over6?
Qi: no

Ted: this seems softwire WG requirement

Suresh: as softwire chair, read this draft, but not have made up mind yet.

Ian: explain the history of the document

Bernie: Suresh to review with possible updates and then initiate WGLC on
mail list


*** DHCPv6 Failover Update
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-4.pdf)

Kim talking about DHCPv6 failover update

No comments


*** DHCP Privacy Considerations
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-6.pptx)

Tomek talking about DHCP privacy considerations

Tomek: is the WG interested in working on this?

Bernie: first step is to write a document

Ted: useful work

Daniel Gillmor: happy to help from outside of DHC WG

Lorenzo: the work is too difficult; recommend not working on this

Daniel: if so, we should document the difficult

Francis: analysis first, don't jump to any solution yet

Suresh: there are spaces within DHCP to improve (The document Daniel mentioned
is RFC 6973 - Privacy Considerations for Internet Protocols)

Ted: IESG is interested in privacy, even give some hint whether using DHCP or
not

Lorenzo: support analysis work first, disagree analysis and solutions doing
at the same time

Mikeal Abramhamsson: SEND is hardly ever alive in practice, so please develop
something deployable

Bernie: Look at RFC 6973 and 7285

Tomek: who is interested to work on it?

Suresh, Sheng, Tomek, Andrew, Daniel Gillmor, Ted raise hands


*** DHCP for Dynamic GRE Tunnel
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-3.pdf)

Li Xue talking about DHCP for dynamic GRE tunnel

Bernie: question for AD, is DHC WG right place for this work?

Ted: where the requirements come from?

Li Xue: OPS open WG

Ted: need OPS AD to request this

Ian: 1. many terms in the draft makes the draft hard to understand
2. There is no standard track for GRE over IPv6

Andrew: CAPWAP may be better option


*** Support for Multiple Provisioning Domains in DHCPv6
(http://www.ietf.org/proceedings/90/slides/slides-90-dhc-9.ppt)


Suresh talking about support for multiple provisioning domains in DHCPv6

Suresh: it is an ongoing work in MIF WG

Ian: DHCPv6 relay agent supporting OPTION_PVD_ID would be useful