Skip to main content

Minutes for DHC at IETF-88
minutes-88-dhc-3

Meeting Minutes Dynamic Host Configuration (dhc) WG
Date and time 2013-11-05 17:00
Title Minutes for DHC at IETF-88
State Active
Other versions plain text
Last updated 2013-12-23

minutes-88-dhc-3
The DHC WG met on Tuesday 0900-1130 at IETF-88 (in Vancouver).

The meeting started with Bernie Volz giving the WG Chairs Update and WG
Status. Sheng Jiang and Suzanne Woolf volunteered to take minutes using
Etherpad (these minutes are based on the Etherpad notes as well as
personal notes taken by Bernie Volz).

Tomek Mrugalski then presented the RFC-3315bis design team slides.

    Tomek: Kick off RFC3315 bis and Design Team Formation
    Tomek: - using issue tracker for WG
           - call volunteers to joint in "Editorial Team",5-6 persons
    Suresh Krishnan: site-local addrs still in use
    Tomek: ok, solved
    Jinmei Tatuya: we can go over the email archive for checking issues
    Tomek: big task
    Alex Petrescu: split the work
    Suresh: separate a mailing list for design team, ask authors of
      RFC3315 first, the issue trackers to be managed well
    Kim Kinnear: How are old RFCs deprecated?

The following volunteered during the meeting to be on the design team:
Suresh Krishnan, Andrew Yourtchenko, Alexandru Petrescu, Sheng Jiang,
Daniel Migault, Marcin Siodelski, Tomek Mrugalski, and Bernie Volz.
Michael Richardson volunteered immediately after the meeting. Tomek
and Bernie will review and follow up with team.

Note: Everyone is encouraged to provide RFC 3316/3633 corrections and
areas with interoperability issues or needing clarification.


Qi Sun presented the DHCPv4 over DHCPv6 Transport slides which
summarized the solution and recent updates to the draft and some
comments received since last draft.

    Kim: not fully clear on behavior of v4 client re: trying over v6 if
      v4 req fails? Timing and required vs. optional
    Suresh: it is clear designed, but not clear described in the draft
    Qi Sun: will improve it
    Ted Lemon: that's obvious
    Francis Dupont: any implementation?
    Qi: yes
    Ted: worth of considering dhcpv6 client connect to multiple servers
    Bernie: it may not be matter as long as the client can get address

After an updated document is published, a Working Group Last Call will
be initiated.


Then Ian Farrer presented the Provisioning IPv4 Configuration over IPv6
only networks and discussed recent updates to the draft and a potential
new evaluation criteria.

    Sheng: this should be discussed in softwire WG
    Ted: the question should be to focus on DHCPv4 over IPv6
    Comments: this is not interest requirement although it can be
      implemented
    Bernie: the final question is DHCPv4 over Softwire vs. DHCPv4 over
      DHCPv6 WG prefers the latter

The recommendation in the draft stands. The recommended solution can
work because IPv6 is always available for a transport. After an updated
document is published, a Working Group Last Call will be initiated.


Shwetha Bhandari next presented the Access Network Identifier Options
slides which included an overview, motivation and use cases, and recent
updates to the draft.

    Kim: single instance is wrong
    Shwetha Bhandari: we can fix this
    Several questioned need for client specified options (relay OK)
    David (?): security consideration for client set this option?
    Suresh: it is not trustable, but based on topology can give some
      reference

An updated document is expected.


Sheng Jiang presented Secure DHCPv6, giving the background and history
of the secure DHCPv6 work and an overview of the proposed solution,

    Jinmei: what is the relationship between this doc and the
      security part in RFC3315
    Sheng: addition, support one to multiple model
    Michael Richardson: tried 10 years ago, appreciate this be worked
      out
      Size of messages with certificate is a concern? Consider URI/URL?
      Time is needed for security - how will this be addressed?
      Clarify that certificate OR public key, not both?
      Consider applicability and limitations (real time clock needed),
      large messages. IKE has similar issues and should consider using
      payload from them? Relay issues with large message size?

The call for adoption will complete Nov 11 and be announced shortly
thereafter.


Qi Sun presented Handling Unknown DHCPv6 Messages with an overview of
the recent changes.

    Kim: move the conclusion to early part to be clear

After an updated document is published, a Working Group Last Call will
be initiated.


Suresh Krishnan presented Address Registration with a review of the
recent changes.

    Authors think the draft is ready for WGLC
    Mikael: security consideration should be added for address ownership
      checking
    Erik Kline: what about temp address?
    Suresh: will add some text regarding to this
    Jinmei: use case
    Suresh: SLAAC address to get registered in DNS through DHCP server
    Bernie: what about lifetimes and removing the FQDN from DNS?
    Bernie: lack 'required' reply messages seems odd
    Ted: temp address is important, should add some text. This is clear
      use case for home net
    Erik: may be add PTR record

An updated document is expected to address points raised.


Sheng Jiang presented DHCPv6 Stateless Reconfiguration discussing the
problem and proposed solution, and raised 4 questions for the WG.

    Sheng: question to the WG, agree the problem or not
    Ted: in principle it is, but any use cases require this function?
    Sheng: e.g. the DNS server renumbered
    Ted: only flash renumbering has the problem, but flash-renum is
      wrong
    Jinmei: personally agree the gap
    ???: proposed a use case
    ???: also provides use cases, in homenet with multiple upstreams
    Suresh: agree with the problem, but proposed another solution
    Bernie: provoke discussion in 6man or v6ops

The discussion was mostly about whether this is a real problem and
whether DHCP was the best way to solve it. It was suggested that if
this was a real problem, it needs wider visibility. There seemed to
be a small group of people who were very convinced about validity of
the problem and were eager to spend time on it.


Kim Kinnear presented DHCPv6 Active Leasequery slides which introduced
what this is, why it is needed, related DHCPv4 work (which was never
adopted), how it works, and decision trees about how to move forward.


There was support for adopting the DHCPv6 work by those in attendance.
The DHCPv4 part of the work was found not appealing to people in the
room. Adoption call to be issued after IETF.


Shwetha Bhandari presented DHCPv6 Dynamic Reconfigure, reviewing
recent updates to draft-wing-dhc-dns-reconfigure, the problem and use
case.

    Ted: the draft creates a problem: dual stack should always connect
      to IPv6 only
    Ted: asked if on charter?
    Ted: what router vendors plan to implement (Cisco as authors are
      from there)
    Simon Perreault: likes the solution
    Bernie: maybe better to add a DNS64 option?
    Simon: the DNS64/NAT64 is there to not require client changes.
      Using a separate option requires client changes.


Alexandru Petrescu presented Route Problem at Relay during DHCPv6
Prefix Delegation discussing typical deployments and requirements,
with several possible solutions.

    Several hands think this is interesting work and should improve the
      draft
    Ted: the right place should be routing area, although it is DHC
      related.


The WG meeting ended without Daniel Migault presenting the homenet
Naming Architecture Options as we ran out of time. This will be
presented in homenet.


There were about 60 people in attendance. We had one remote participant
using WebRTC client running on iPad.