Subject: Notes from design team teleconference, 8/31

From: Ralph Droms <[email-masked]>
Date: Mon, 02 Oct 2000 11:30:14 -0400

Here are the final minutes from the design team teleconference held 8/31:

DHCPv6 Interim WG Meeting
telephone conference call
31 August 2000

1.  Agenda Bashing

1.1. develop milestones and calendar
      --working group Last Call begins 5 January 2001
      --need final version by San Diego WG meeting 10 Dec 2000
          --IETF I-D cutoff is mid-November
          --suggest publication-review-republication cycle:
            ==publish first draft by September 30
            ==intermediate review by October 10

      Ted brought up the issue of how the document would be revised,
      and Mike and others agreed that the revision process should
      include anybody in the meeting who's interested.

      Final calendar for spec development:
         9/30/2000 - Publish revised spec based on this teleconference
        10/10/2000 - Interim WG meeting to review spec
        11/15/2000 - Publish revised spec based on interim meeting;
                     this revision will be ready for final WG review
        12/1x/2000 - Final WG review of spec in San Diego
         1/ 5/2001 - WG last call begins

1.2. agenda for this meeting

      * review features list and edit for clarification and refinement
        of issues
      * discuss open issues as time permits
      * develop strategy for resolving open issues

2. features list bashing

2.1. Use of multicast instead of broadcast
      "Yes, of course."

2.2. Use of globally-unique "client identifier":  link-local
      address may not be sufficiently "permanent" for client
      lease identification
          --suggest mandatory identifier
          --construct from prefix and link-local:
            ==link-local addresses are unique per IPv6 subnet
            ==prefixes must not be duplicated on multiple subnets

      Mark Stapp: client id plays into:
      - only link-local address as identifier - issues with allocating new
        addresses.   Client generates new ID by appending to identifier.
      - Discussion on whether identifier should be optional; Mark says yes
        because the space requirement for low-bandwidth clients is onerous.
        Mike and Barr (?) say no, because it makes the protocol too
        complicated.  Barr: mobile case - devices are
        difficult/impossible to alter UID. Jim: Identifier is
        combination of prefix and link-local address.
      - Ralph: need delivery address (MAC, link-local IP), need GUID;
        two functions are separate: message delivery, client identification.
      - Is it separable as client id and association ID?   Client, link or
        address ID?

2.3. Cleaner and simpler message formats.
      --some overlap with other goals

2.4. Avoid stateful server (in terms of the protocol interaction).
      --avoid transaction ID cache for correct server operation
      --retain opacity of XID from DHCPv4

2.5. Reduce number of ways to release resources

      "Yeah.  Get rid of C bit."

2.6. Where appropriate, keep v4 and v6 options/extensions "the
      same."  Use the same option numbers.  Use the same format
      (except for 16-bit type/length).
	--enforce v4 and v6 consistency?

      Mike: there's a lot of baggage in DHCPv4.   We have a fresh start
      here, should take a careful look at the options that we are
      defining for DHCPv6.   Ralph: leaving holes not a problem.
      Should capture options for both protocols at the same time.
      Barr: option/extension names should be rational.   There are cases
      where it's not clear whether an option is for one purpose or
      another.   Name should be as completely descriptive of the purpose
      as possible.  Ralph: two subtopics - rigidly enforce same option
      set; try to keep options coordinated in the future?   Transition
      doc?

2.7. Define DHCPng as ONE new protocol can that can accommodate
      IPv4 and IPv6 address assignments.
	--suggest for future work
	--some overlap with items 22 and 23
	--can new option namespace bridge the gap?
	--BCP for transition implementors?

      Ralph: rathole horn ready.   Mike: keep them separate.   Barr: do
      this later.   Jim: client would have to have V4/V6 path.   Mark:
      don't want to lose opportunity.   Ted: make sure it's possible to
      write companion document for DHCPv6v4.   Ralph: have an
      opportunity to revise thinking about DHCPv4, and if we don't think
      about it we may lose this opportunity.   Jim: HTTP (?) does really good
      job of building a new transfer protocol where there is no address
      in the header, might want to look at it.   Ted: moving to telco
      two-packet startup requires DHCPv4-ish semantics.   Jim: if we
      sacrifice performance for DHCPv6 to get DHCPv4 compatibility this
      is a lose.   Bernie: nobody wants this.

      *** Don't need to discuss this further.   Agreed that it should be
	possible to do this, but not done in spec.

2.8. Allow Reconfigure and Reconfigure-reply messages to be sent
      via a relay to client's which do not have such reachable IP
      addresses, in order to inform them of changes in non-
      releasable resources?  The same thing could also go for
      Reconfigure-init to some extent.
	--combine with item number 18

2.9. Might a client send a Solicit in response to a Reconfigure-
      init?  What if the topology changes such that this is
      necessary in order find a DHCP server with can allocate
      addresses on the new subnet?

2.10. Smaller DHCP message header for B/W efficiency.

2.11. Reduce the number of messages to configure a node; e.g.
       * a two-message lease binding
       * permitting a client to obtain 1-n addresses as needed
	rather than all at "boot" time
		--should be part of address model discussion

       Ralph: this is an application of the DRCP work, where we have a new
       allocation and server is happy to commit it in initial transaction.
       Mark: you can bypass the solicit/advertise part of the transaction.

2.12. To rapidly configure roaming users, avoid ND Neighbor
       Solicitation and Neighbor Advertisement, both for the
       link local addresses and the address given by DHCP.
	      --suggest for future work

       Ralph: future work.   Bernie: server could do this for client if on
       same link.   Mark: interesting if someone could expand on this.

2.13. Configure a router's interface if it is on the same
       link as the DHCP server.
	      --suggest for future work

       Ralph: future work.  Mike: yes.   Ted: yes.

2.14. Define a new interface to DHCP for doing things such
       as adding a new address pool, changing some
       configuration parameters, or being able to request a
       new address pool.
	      --interesting, but should be future work

       Ralph: future work, not part of this effort.

2.15. No state transition diagram in spec

       Various people say state diagram helps to understand specification.
       Barr: agrees with Ted.   Mike: tried to give 50k foot overview, so
       maybe state diagram not needed.   Jim: shouldn't even have a state
       architecture anyway.

2.16. A single fixed header for (at least) Solicit,
       Advertise, Request, Reply, and Release messages,
       rather than different headers for different messages,
       with most information in extensions;  get rid of mode
       bits wherever possible;  multi-bit numbers should be 8,
       16, 32, 64 or 128 bits;  there should be no reserved
       fields in extensions.
	      --consider along with item 3

2.17. Use the delayed authentication mechanism that DHCPv4
       has been developing.

       Mike: fine with me.   Ralph: related to relay agents.

2.18. Simplify reconfiguration;  Use DHCPv4-style reconfiguration
       --being considered along with items 8 & 9

       Mike: just want a reconfigure message that causes the client to
       reinitialize.   ???

       Bernie: not addressed in current design: if you multicast reconfigure,
       server has addresses no client has allocation for, ???

       Mike: clients should listen for multicast.
       Jim: Do reconfigure-init only with unicast, not multicast.
       Mike: must specify multicast reconfigure stuff now if clients are
       going to support it.

       *** Current draft just does DHCPv4-style reconfigure, which is a
	  trigger to do an init.
       *** Discuss or defer on multicast.   If we come to resolution, great.

2.19. Consider IPv6 address compression.

       Mike: I'm considering it.   Jim: as an option it could be nice.
       Ralph: future work.

2.20. Support a client-identifier hierarchy, a la DHCPv4.
       --consider along with item 2

2.21. Address model:
       * One interface, with a single unique identifier, can be
	assigned multiple addresses
       * Server knows exactly what addresses to assign to client
       * Client asks for "configuration", which includes assigned
	addresses
       * Client may extend leases on addresses individually
	      --related to client identifier discussion (global vs.
		link-local uniqueness)

2.22. Messages and semantics
       * Rename messages and change semantics to match RFC2131
       * Use message exchanges from RFC2131
       * Change formats to optimize message size and carry
	IPv6 addresses
	      --e.g., what is the difference between Discover and
		Solicit?
	      --should we use the same message names?
	      --are the message semantics different?

       Ted: We don't know yet whether this makes sense; depends on other
       issues.   Ralph: why is there a difference?   If there's no
       advantage to different format, suggest adopting RFC2131 model.
       Bernie: what are they called versus format.  Easier to have
       different names for reference in option RFCs.   Mike: Have
       solicit instead of discover because: Solicit enables client to
       find agent; does not provide address.   Reason for this is that
       you might want to locate server when client is first initialized
       and not visit them until prompted by application later.   Maybe
       this doesn't make sense.  Ralph: identify what the conversation
       points are but not answer question.   Josh: there's an advantage
       to preserving DHCPv4 semantics because it makes DHCPv6 deployment
       easier in terms of administrative understanding and also server
       implementations.

2.23. Relay agents -- adopt DHCPv4 function:  relay agents
       insert interface address in 'giaddr' and forward to
       DHCP servers
	      --consider along with item 26

       Jim: why do people think this isn't in DHCPv6?   Mike: new one is
       stateless.   Ralph: relay agent inserts address in solicit but
       not in request.   Jim: we do permit relays to handle ICMP Path
       MTU message back to client.

2.24. Discard references to "releasable resources"
       --general consensus
	      --see item 29

2.25. What happens when the network type is ambiguous?
       could be IPv6, could be IPv4.
	      --timeout based on router solicit?
	      --start with DHCPv4 Discover
	      --v6 clients begin with auto-configure, must be told
		to use DHCPv6
	      --topic for transition BCP

      Jim: because I have IPv6 and running DHCPv6, don't use my product
      if you're using v4.   Bernard: why shouldn't clients that want
      IPv4 addresses use DHCPv4 to get them?

2.26. Relay agents should simply encapsulate the client
       message in a DHCPv6 extension;  the relay message
       should have its own type.
	      --consider along with item 23

2.27. Any bits in extensions that change the meaning of the
       extension type for the whole extension should be
       represented as new extensions.
	      --consider along with item 3, message formats

       Bernie: suppose we want to add something else that's included in
       the option?   If you do bulking and use address option as marker,
       this works nicely.

2.28. The client, when it is referring to an address it
       wants to renew, should be able to reflect back at the
       server the exact IP Address extension that it got
       from the server, rather than having to tweak it.

2.29. Releasable resources should be documented in a
       separate draft.
	      --see item 24

2.30. Why 'extensions' and not 'options'?
       --consider along with item 22

2.31. Bernie: consider an encapsulation for IP addresses.

2.32. Francois wants to change the name.  Wants to lose extensions that
       "aren't really needed" for DHCP, e.g. Posix Timezone.

3. assign review editors for items; note that this list combines items
    from 2. that were identified as belonging together

3.1. Use of multicast instead of broadcast
      * done

3.2. Use of globally-unique "client identifier"
      --incorporates item 20:
        Support a client-identifier hierarchy, a la DHCPv4.
      --is it a client ID or a link ID or a node ID?
      * Ted taking responsibility

3.3. Cleaner and simpler message formats.
      --incorporates items 10, 16, 27 and 28:
        Smaller DHCP message header for B/W efficiency.
        A single fixed header;  multi-bit numbers should be
           on octet boundaries;  no reserved fields in extensions.
        Any bits in extensions that change the meaning of the
           extension type for the whole extension should be
           represented as new extensions.
        The client, when it is referring to an address it
           wants to renew, should be able to reflect back at the
           server the exact IP Address extension that it got
           from the server, rather than having to tweak it.
      * defer to next draft

3.4. Avoid stateful server
      * done

3.5. Reduce number of ways to release resources
      * done

3.6. Where appropriate, keep v4 and v6 options/extensions "the
      same."
      * Bernie taking responsibility

3.7. Define DHCPng as ONE new protocol can that can accommodate
      IPv4 and IPv6 address assignments.
      * future work

3.11. Reduce the number of messages to configure a node.
       -- take to mailing list for discussion
       * Mark taking responsibility

3.12. Avoid ND Neighbor Solicitation and Neighbor Advertisement.
       * future work

3.13. Configure a router's interface if it is on the same
       link as the DHCP server.
       * future work

3.14. Define a new interface to DHCP for some things.
       * future work

3.15. No state transition diagram in spec
       * defer decision

3.17. Use the delayed authentication mechanism from DHCPv4.
       * done

3.18. Simplify reconfiguration;  Use DHCPv4-style reconfiguration
       --incorporate with items 8 & 9:
         Allow Reconfigure and Reconfigure-reply messages to be sent
           via a relay.
         Might a client send a Solicit in response to a Reconfigure-
           init?
       --unicast Reconfigure-init
       * Bernie taking responsibility

3.19. Consider IPv6 address compression.
       * future work

3.21. Address model changes:
         --One interface, with a single unique identifier, can be
           assigned multiple addresses
         --Server knows exactly what addresses to assign to client
         --Client asks for "configuration", which includes assigned
           addresses
         --Client may extend leases on addresses individually
                 --related to client identifier discussion (global vs.
                   link-local uniqueness)
         * Ted taking responsibility

3.22. Messages and semantics aligned with RFC 2131
       --incorporate item 30:
         Why 'extensions' and not 'options'?
       * Ted taking responsibility

3.23. Relay agents adopt DHCPv4 function
       --incorporates item 26:
          Relay agents should simply encapsulate the client
            message in a DHCPv6 extension;  the relay message
            should have its own type.
       * Barr taking responsibility

3.24. Discard references to "releasable resources"
       * done

3.25. What happens when the network type is ambiguous?
       could be IPv6, could be IPv4.
       * topic for transition BCP

3.29. Releasable resources should be documented in a
       separate draft.
       * future work

4. Address Model

4.1 features

4.1.1 get more than one address per interface

4.1.2 get addresses at any time (on-demand)

     - N IP addresses per interface, per client?
     - allocate new ones on demand?
     - dependency on structure of client id.
     - What part of the ID is used for authentication?
     - Bernie says must be GUID.

4.2. candidates

     - to be discussed on mailing list