Minutes for DHC at IETF-96
minutes-96-dhc-2

DHC WG (IETF-96, Berlin) Minutes

Date: Wednesday, July 20, 2016, 10:00-12:30 Wednesday Morning session I (CEST)
Location: Tiergarten
Chairs: Tomek Mrugalski & Bernie Volz
Secretary: Sheng Jiang

These minutes are based on the Etherpad notes taken by Tomek with some edits
from Bernie Volz.

 1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) - 5 minutes

 2. Secure DHCPv6 and Secure DHCPv6 Deployment, Ted Lemon - 20 minutes
    draft-ietf-dhc-sedhcpv6
    draft-li-dhc-secure-dhcpv6-deployment
Francis Dupont: increasing numbers is a problem for clients that don't have
  stable storage
Ted Lemon: you can use stable storage or clock, the spec doesn't enforce one or
  the other
Bernie Volz: suggestion to extend the sequence number field to 64 bits, so we
  could get millisecond resolution
Ted: agree

 3. Security of Messages Exchanged Between Servers and Relay Agents,
      Bernie Volz & Yogendra Pal - 10 minutes
    draft-volz-dhc-relay-server-security
Suresh Krishnan: Look at RFC4107 to see if manual keying meets requirements.
Hum indicates the those in audience support adoptiong this as a working group
  item; adoption call to be issued on WG ML in near future.

 4. Next Steps for DHCPv6 failover, Tomek Mrugalski - 10 minutes
    draft-ietf-dhc-dhcpv6-failover-protocol
Discussion about possible choices.
Marcin Siodelski promised to review the draft.
Ian Farrer: we came up with a different solution to the problem, so std solution
  is not needed.
Hum indicates the WG prefers option A: redo the WGLC (the alternatives were:
  B - publish as experimental (silence), C - drop the work (silence))

 5. YANG Data Model for DHCPv6 Configuration, Linhui Sun - 15 minutes
    draft-ietf-dhc-dhcpv6-yang
Discussion about options storage and how to define it.

Francis: Need way to handle new dhcpv6 options and vendor options
Yopendra: do you support context (any arbitrary set of data addigned) in the
  model?
Linhui: no
Marcin: comment about option storage. It's confusing to have 3 different ways
  to define options. We have option defintion in Kea and option values that
  use those definitions.
Ian: the reason why we did 7227 options is because this was the recommendation
  of the WG last time.
Yogendra: Raised question about context - will follow up on mailing list
Alex Pertrescu: asking if the model was developed from scratch or from MIB.
Suresh: There's a draft draft-ietf-netmod-opstate-reqs-04, you should look at.

 6. DHCPv6 Prefix Length Hint Issues, Linhui Sun - 10 minutes
    draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
Marcin: Slide 6 "must neglect" doesn't consider RFC7550 (Stateful Issues) if
  addresses also requested and provided by server.
Ian: need to clarify the behavior of a client that needs exactly the prefix
  it hinted and any other prefix is not good enough. (The text on slide 3 is
  oddly worded and should reflect server's granting or not granting the
  client's requested delegated prefix.)
Suresh: Is "SHOULD include" appropriate? Why not "MUST include"?

 7. Generalize Client UDP Port Number of DHCP Relay, Naiming Shen - 10 minutes
    draft-shen-dhc-client-port
Francis: as a reviewer of the code I confirm using source and destination
  ports is a nightmare.
Ian: the number of packets in avergage network I saw is couple to tens of
  thousands, given the lease of a day this gives you couple packets per
  second. Do you really need many processes?
Naiming: we have the WLAN controller that handles many APs.
Marcin: the draft says it can run on any port,
Normen Kowalewski: if there's a load balancer, you can split across ports
  or addresses. Is there a rationale for one over the other?
Bernie: from my perspective, in IPv6 it's not a big deal, but in IPv4 it may be.
(unknown):If you take a look at the average unix application, it doesn't
  ncessarily care about its source port, just the destination, so the returning
  packet is a problem.
Bernie: do people think this is useful and whether we should adopt it. Not so
  strong hum for adoption support, silence for against adoption.

 8. DHCPv6bis update & issues discussion, dhcpv6bis team - 15 minutes
    draft-ietf-dhc-rfc3315bis
Issue #162
Marcin: I'm fine with option 2.
Suresh: we should not go with 2, because of possible conflicts. I prefer 3.

Consensus determination:
DUID-LL humm (dead silence)
Remove the restriction (some humm, but not very strong)
Don't do anything (loud humm)

#166 - text to update RFC 3315 in draft-ietf-6man-default-iids-13:
Suresh: I don't like the replacement text.
Brian: the draft being referenced in the replacement text. It uses the
  parameters based on something that has to be stable. The concern I have is
  that the server would have to keep it. The concern was that this draft
  brought comments about overspecifying what DHCP implementors do. I would
  prefer "these are the characteristics your allocation should follow (full stop)".
Suresh: start with the current text and add references to RFC7136? The RFC5453
  is two generations old.

#167 - Use the term "Client" rather than "requesting router" from Lorenzo's
  email to WG:
Ian: Relays glean the PD and do route injection. This is something that is
  not mentioned at all.
Bernie: we discussed that during pre-meeting, and thought that maybe mentioning
  that the problem of route injection may appear and there are solutions that
  snoop the prefix from passing traffic. This will become more complicated
  if/when the sedhcpv6 is deployed.
Marcin: if we decide to move delegating router => client, this will also
  affect the prefix-length-issue draft.
Alex Petrescu: There's a draft already about relay-insertion-draft
  (https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem).

Yogendra Pal volunteered to review the draft.