From owner-dhcp-v6@bucknell.edu  Sun Oct  1 14:51:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11046;
	Sun, 1 Oct 2000 14:51:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e91IlNb06372;
	Sun, 1 Oct 2000 14:47:23 -0400 (EDT)
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e91Ikxb14458
	for <dhcp-v6@bucknell.edu>; Sun, 1 Oct 2000 14:47:08 -0400 (EDT)
Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132])
	by palrel1.hp.com (Postfix) with ESMTP id 56354A70
	for <dhcp-v6@bucknell.edu>; Sun,  1 Oct 2000 11:46:57 -0700 (PDT)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id AAA16314 for <dhcp-v6@bucknell.edu>; Mon, 2 Oct 2000 00:15:50 +0530 (IST)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <39D78724.B3BC4DD2@dce.india.hp.com>
Date: Mon, 02 Oct 2000 00:19:09 +0530
From: vijaya bhaskar <vijayak@dce.india.hp.com>
Organization: hp ISO
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.10 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6 DHCPv4 inetoperability ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: vijayak@india.hp.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Hello,

DHCPv4 client and server has different port number compared to DHCPv4
client and agent. Is it mean that the dhcpv4 and dhcpv6 should run as
different services ?

what i have undestood is, if the client needs to be configure with v4
address, then it should contact DHCPv4 server and if it needs v6
address, it should contact DHCPv6 server. am i correct ?

Is there any way of interoperability between dhcpv4 and dhcpv6 servers ?

Regards,
Vijay



From owner-dhcp-v6@bucknell.edu  Mon Oct  2 11:06:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08832;
	Mon, 2 Oct 2000 11:06:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e92F3Cb21952;
	Mon, 2 Oct 2000 11:03:12 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e92F3Bb05628
	for <dhcp-v6@bucknell.edu>; Mon, 2 Oct 2000 11:03:11 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NT7J>; Mon, 2 Oct 2000 11:02:55 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603606FDD@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 2 Oct 2000 11:02:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I do think the wording below will need some rework. For example: "Clients
that have no stable storage MUST use the link-layer address of one of their
network interfaces as the client identifer, and MUST use the same client
identifier for all of their interfaces."

If a client has other unique identifying information, such as a unique
serial number burned into memory it should use that and not any network
interface information. Therefore the "MUST" MUST be removed or changed to be
conditional.

I believe the rules should be:

1) If a client has previously stored a unique identifier in stable storage,
it MUST use this for all its interfaces.
2) If a client has unique identifying information (such as a serial number)
that it can use as a unique identifier, it MUST use this (after storing it
in stable storage if possible).
3) If a client does not have unique identifying information and it has
stable storage, it should generate a unique identifier by combining the
link-layer address of one or more network interfaces, padded with zeros at
the end to a total length of sixteen bytes, with a randomly generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to produce a
unique identifier, and should store this identifier in stable storage.
4) Otherwise, the client must generate a unique identifier in a way that the
same value is likely to be generated each time it boots, such as by using
the link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Thursday, September 28, 2000 9:54 PM
To: DHCPv6 discussion list
Cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal...



> How do we verify that a clients IA is in fact unique if it don't verify
> that with other clients?
>  a) on the link best case
>  b) with the servers dhcp domain?

The schemes that have been proposed for coming up with UUIDs
(Universally Unique Identifiers) rely more on reducing the chance of
collision to ridiculously low amounts than they do on any mechanical
process of guaranteeing that the identifier is unique.  I am pretty
sure that Windows has a UUID that is generated this way.   Computers
with serial numbers could use a vendor name plus the serial number.

I think the language in the draft should say something like "DHCP
clients SHOULD use a client identifier that will not vary as a result
of changes in network hardware and will be consistent between network
interfaces.  DHCP clients SHOULD NOT use the link-layer address of a
network interface by itself as a client identifier, but SHOULD instead
use some other identifier that is known to be globally unique - for
example, a combination of the CPU's serial number and manufacturer's
registered domain name.   DHCP clients that have no unique identifier
other than the link-layer address SHOULD combine the link-layer
address of one or more network interfaces, padded with zeros at the
end to a total length of sixteen bytes, with a randomly-generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to
produce a unique identifier, and should store this identifier in
stable storage.   Clients that have no stable storage MUST use the
link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces."

This is rather convoluted, but I think it covers all the possible
cases where one could get into trouble.   The only case where we could
get into trouble is if two clients connected to the same link use the
HASH (pad16 (link-layer-addr) + random4) and wind up producing the
same hash value.   The reason for using the highly-structured formula
for producing the hash is to make this vanishingly unlikely, but I'm
not a crypto-geek, so I may have gotten it wrong.

We could also require the client to identify which of the algorithms
it is using in the first byte of the identifier, which would avoid
stupid collisions due to differing algorithms.

The language should also probably be made more readable - I'd be happy
to do this if people think this is a good set of methods to use to
generate the client identifier.

BTW, I am just talking about how to generate the common per-client
part of the identifier.  We also talked about the client combining its
per-client identifier with an additional per-instance identifier so as
to uniquely identify an address association, so that the client could
have more than one address association - e.g., for application-
specific situations or for clients supporting more than one interface,
or using DHCP to manage a care-of address as well as a home address.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Oct  2 11:33:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09565;
	Mon, 2 Oct 2000 11:33:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e92FWob14985;
	Mon, 2 Oct 2000 11:32:50 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e92FWab25083
	for <dhcp-v6@bucknell.edu>; Mon, 2 Oct 2000 11:32:36 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA06971 for <dhcp-v6@bucknell.edu>; Mon, 2 Oct 2000 11:32:16 -0400 (EDT)
Message-Id: <4.3.1.2.20000925143608.00c0b970@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 02 Oct 2000 11:30:14 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Notes from design team teleconference, 8/31
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

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




From owner-dhcp-v6@bucknell.edu  Mon Oct  2 13:29:27 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11390;
	Mon, 2 Oct 2000 13:29:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e92HMsb04181;
	Mon, 2 Oct 2000 13:22:54 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e92HMnb19696
	for <dhcp-v6@bucknell.edu>; Mon, 2 Oct 2000 13:22:49 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8N41J>; Mon, 2 Oct 2000 13:22:34 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603606FE4@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 DHCPv4 inetoperability ?
Date: Mon, 2 Oct 2000 13:22:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Vijay:

DHCPv6 is still being designed. But, there is no direct
compatibility/interoperability between DHCPv4 and DHCPv6 - packet formats,
message types, etc are all different.

If a system is running both IPv4 and IPv6 and is using DHCP for addressing,
then it does need to run both of these protocols (DHCPv4 will assign the v4
addresses and DHCPv6 will assign the v6 addresses).

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: vijaya bhaskar [mailto:vijayak@dce.india.hp.com]
Sent: Sunday, October 01, 2000 2:49 PM
To: DHCPv6 discussion list
Subject: DHCPv6 DHCPv4 inetoperability ?


Hello,

DHCPv4 client and server has different port number compared to DHCPv4
client and agent. Is it mean that the dhcpv4 and dhcpv6 should run as
different services ?

what i have undestood is, if the client needs to be configure with v4
address, then it should contact DHCPv4 server and if it needs v6
address, it should contact DHCPv6 server. am i correct ?

Is there any way of interoperability between dhcpv4 and dhcpv6 servers ?

Regards,
Vijay



From owner-dhcp-v6@bucknell.edu  Mon Oct  2 16:00:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13431;
	Mon, 2 Oct 2000 16:00:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e92JvSb25292;
	Mon, 2 Oct 2000 15:57:28 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e92JvLb15474
	for <dhcp-v6@bucknell.edu>; Mon, 2 Oct 2000 15:57:22 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-68.ip.theriver.com [206.97.58.68]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA10841; Sun, 1 Oct 2000 09:21:40 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e92JtJ101640; Mon, 2 Oct 2000 12:55:23 -0700 (MST)
Message-Id: <200010021955.e92JtJ101640@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Mon, 02 Oct 2000 11:02:54 -0400." <63D30D6E10CFD11190A90000F805FE8603606FDD@lespaul.process.com> 
Date: Mon, 02 Oct 2000 12:55:19 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> If a client has other unique identifying information, such as a unique
> serial number burned into memory it should use that and not any network
> interface information. Therefore the "MUST" MUST be removed or changed to be
> conditional.

Oh, good point.

> 2) If a client has unique identifying information (such as a serial number)
> that it can use as a unique identifier, it MUST use this (after storing it
> in stable storage if possible).

It should compute SHA over this - we don't want to be using an
unmasked serial number any more than we want to use an unmasked
ethernet address.

> 4) Otherwise, the client must generate a unique identifier in a way that the
> same value is likely to be generated each time it boots, such as by using
> the link-layer address of one of their network interfaces as the client
> identifer, and MUST use the same client identifier for all of their
> interfaces.

This sounds good!

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Oct  4 21:38:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06865;
	Wed, 4 Oct 2000 21:38:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e951ZWb07728;
	Wed, 4 Oct 2000 21:35:32 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e951ZOb13884
	for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 21:35:24 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05413
	for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 18:35:18 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id SAA05716
	for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 18:35:18 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e951ZGh480897
	for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 18:35:16 -0700 (PDT)
Date: Wed, 4 Oct 2000 18:34:53 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: RE: DHCPv6 address model proposal...
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <63D30D6E10CFD11190A90000F805FE8603606FDD@lespaul.process.com>
Message-ID: <Roam.SIMC.2.0.6.970709693.5419.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Bernie,

 > 2) If a client has unique identifying information (such as a serial number)
> that it can use as a unique identifier, it MUST use this (after storing it
> in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.

   Erik



From owner-dhcp-v6@bucknell.edu  Wed Oct  4 22:02:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07048;
	Wed, 4 Oct 2000 22:02:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9521mb15334;
	Wed, 4 Oct 2000 22:01:48 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9521hb05357
	for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 22:01:43 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NW6Z>; Wed, 4 Oct 2000 22:01:28 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607022@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 4 Oct 2000 22:01:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

By all means. I wasn't trying to provide the exact text, just trying to
improve on what was being proposed. Details will need to be filled in.
Likely, we would also want a prefix to identify how the unique identifier
was created in all cases - that would help to assure each technique of
generating the identifier produces a unique identifier.

I also suspect that there is some 'prior art' on this matter in other places
and that should be used and referenced if at all possible.

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@ENG.SUN.COM]
Sent: Wednesday, October 04, 2000 9:35 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 address model proposal...



Bernie,

 > 2) If a client has unique identifying information (such as a serial
number)
> that it can use as a unique identifier, it MUST use this (after storing it
> in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.

   Erik



From owner-dhcp-v6@bucknell.edu  Thu Oct  5 01:37:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14459;
	Thu, 5 Oct 2000 01:37:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e955YWb17289;
	Thu, 5 Oct 2000 01:34:32 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e955YSb15474
	for <dhcp-v6@bucknell.edu>; Thu, 5 Oct 2000 01:34:29 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a9.pm3-32.theriver.com [206.102.192.73]) by toccata.fugue.com (8.10.2/8.6.11) with ESMTP id e955YJc23641 for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 22:34:20 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e955Wa715415 for <dhcp-v6@bucknell.edu>; Wed, 4 Oct 2000 22:32:37 -0700 (MST)
Message-Id: <200010050532.e955Wa715415@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 04 Oct 2000 22:01:25 -0400." <63D30D6E10CFD11190A90000F805FE8603607022@lespaul.process.com> 
Date: Wed, 04 Oct 2000 22:32:36 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Details will need to be filled in.

Someone has to do this, of course.   We're into the rewrite period at
this point - can the authors say how they are doing, and whether or
not they would like some help, or whether they don't feel they have
anything to go on yet?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Oct  5 22:19:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10889;
	Thu, 5 Oct 2000 22:19:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e962H1b11448;
	Thu, 5 Oct 2000 22:17:01 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e962Gkb32396
	for <dhcp-v6@bucknell.edu>; Thu, 5 Oct 2000 22:16:46 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 63B7D3636; Thu,  5 Oct 2000 22:16:31 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 4FF3137B3
	for <dhcp-v6@bucknell.edu>; Thu,  5 Oct 2000 22:16:31 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000835849; Thu, 5 Oct 2000 22:15:46 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010060215.WAA0000835849@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 04 Oct 2000 22:32:36 PDT."
             <200010050532.e955Wa715415@grosse.bisbee.fugue.com> 
Date: Thu, 05 Oct 2000 22:15:45 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Ted,

>> Details will need to be filled in.

>Someone has to do this, of course.   We're into the rewrite period at
>this point - can the authors say how they are doing, and whether or
>not they would like some help, or whether they don't feel they have
>anything to go on yet?

Yes we have lots to go on.  Mike and I have been talking to Ralph. Yes
we will want help.  Ralph will be sending note to the design team what
next steps are and then we can get that to the list.

So Yes Yes Yes too all your questions.

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Fri Oct  6 16:41:22 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12474;
	Fri, 6 Oct 2000 16:41:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e96Kcgb29548;
	Fri, 6 Oct 2000 16:38:42 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e96KcYb25352
	for <dhcp-v6@bucknell.edu>; Fri, 6 Oct 2000 16:38:34 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA25591 for <dhcp-v6@bucknell.edu>; Fri, 6 Oct 2000 16:38:18 -0400 (EDT)
Message-Id: <4.3.1.2.20001006163926.00b27df0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 06 Oct 2000 16:40:32 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim, Mike and I had a conversation yesterday about moving the DHCPv6
draft spec along - I offered to give them some help with revving
the spec so we can meet the timeline we laid out at the design
team phone call.  Jim and Mike accepted my offer, so, at this point
I'm going to take responsibility for keystroking the source of the spec
("editing" in the narrowest sense of the word).  I'm also going to write
up summaries of the WG discussion threads that came out of the design team
phone call and get WG consensus on the final resolution of those issues.
Jim, Mike and I will generate text and hammer out a revved spec that
incorporates the WG consensus.

I'm just starting to write up the discussion summaries and edit the spec,
so I can't predict when we'll have the new rev ready and when we can
schedule the next design team phone call.  I'll get back to you with more
details soon.

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Oct  6 16:52:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12614;
	Fri, 6 Oct 2000 16:52:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e96KqNb02970;
	Fri, 6 Oct 2000 16:52:23 -0400 (EDT)
Received: from mail02-oak.pilot.net (mail-oak-2.pilot.net [198.232.147.17])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e96KqMb31968
	for <dhcp-v6@bucknell.edu>; Fri, 6 Oct 2000 16:52:22 -0400 (EDT)
Received: from mail01-gap.gap.com ([206.24.101.33]) by mail02-oak.pilot.net with ESMTP id NAA13559 for <dhcp-v6@bucknell.edu>; Fri, 6 Oct 2000 13:52:20 -0700 (PDT)
From: Relfe_Tan@gap.com
Received: from mailhub02.gap.com ([9.32.202.152]) by mail01-gap.gap.com with ESMTP id NAA02896 for <dhcp-v6@bucknell.edu>; Fri, 6 Oct 2000 13:52:18 -0700 (PDT)
Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43])
	by mailhub02.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id NAA09766;
	Fri, 6 Oct 2000 13:51:10 -0700 (PDT)
Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256970.00728941 ; Fri, 6 Oct 2000 13:51:00 -0700
X-Lotus-FromDomain: GAPINC
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Message-ID: <88256970.007286BC.00@smtpmta01.gap.com>
Date: Fri, 6 Oct 2000 13:48:33 -0700
Subject: UNSUBSCRIBE
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN




From owner-dhcp-v6@bucknell.edu  Sat Oct  7 17:27:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07729;
	Sat, 7 Oct 2000 17:27:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e97LP3b05342;
	Sat, 7 Oct 2000 17:25:07 -0400 (EDT)
Received: from out01b.e-scan.net (out01b.e-scan.net [212.62.8.164])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e97LOub19229
	for <dhcp-v6@bucknell.edu>; Sat, 7 Oct 2000 17:24:56 -0400 (EDT)
Received: from ihs00734.integralis.co.uk (unverified) by out01b.e-scan.net
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <Bc0a800a44f1dfb83e9@out01b.e-scan.net> for <dhcp-v6@bucknell.edu>;
 Sat, 7 Oct 2000 22:23:59 +0100
Received: from IHS_MAIL_01.integralis.co.uk (unverified) by ihs00734.integralis.co.uk
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <Bc3a613e64f1e0064c8@ihs00734.integralis.co.uk> for <dhcp-v6@bucknell.edu>;
 Sat, 7 Oct 2000 22:29:18 +0100
Received: from jajabinks (host212-140-42-6.btinternet.com [212.140.42.6]) by IHS_MAIL_01.integralis.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id QWKHWT7D; Sat, 7 Oct 2000 22:22:39 +0100
Message-ID: <002101c030a5$16c12e30$062a8cd4@jajabinks>
Reply-To: "Paul Barker" <paul.barker@INTEGRALIS.CO.UK>
From: "Paul Barker" <paul.barker@INTEGRALIS.CO.UK>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: UNSUBSCRIBE
Date: Sat, 7 Oct 2000 22:25:07 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative ; boundary="----=_NextPart_000_0017_01C030AD.72A16870"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C030AD.72A16870
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




Integralis
Theale House
Brunel Road
Theale, Reading
RG7 4AQ
+44 (0) 118 9306060

A member of the Articon-Integralis Group

info@Integralis.com
http://www.integralis.com


DISCLAIMER
Any opinions expressed in this email are those of the individual and not ne=
cessarily the Company. This email and any files transmitted with it, includ=
ing replies and forwarded copies (which may contain alterations) subsequent=
ly transmitted from the Company, are confidential and solely for the use of=
 the intended recipient. It may contain material protected by attorney-clie=
nt privilege. If you are not the intended recipient or the person responsib=
le for delivering to the intended recipient, be advised that you have recei=
ved this email in error and that any use is strictly prohibited.

If you have received this email in error please notify the IT manager by te=
lephone on +44 (0)118 930 6060 or via email to internal.security@integralis=
.com, including a copy of this message. Please then delete this email and d=
estroy any copies of it.

------=_NextPart_000_0017_01C030AD.72A16870
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV><CODE><FONT SIZE=3D3><BR>
<BR>
Integralis<BR>
Theale House<BR>
Brunel Road<BR>
Theale, Reading<BR>
RG7 4AQ<BR>
+44 (0) 118 9306060<BR>
<BR>
A member of the Articon-Integralis Group<BR>
<BR>
info@Integralis.com<BR>
http://www.integralis.com<BR>
<BR>
<BR>
DISCLAIMER<BR>
Any opinions expressed in this email are those of the individual and not ne=
cessarily the Company. This email and any files transmitted with it, includ=
ing replies and forwarded copies (which may contain alterations) subsequent=
ly transmitted from the Company, are confidential and solely for the use of=
 the intended recipient. It may contain material protected by attorney-clie=
nt privilege. If you are not the intended recipient or the person responsib=
le for delivering to the intended recipient, be advised that you have recei=
ved this email in error and that any use is strictly prohibited.<BR>
<BR>
If you have received this email in error please notify the IT manager by te=
lephone on +44 (0)118 930 6060 or via email to internal.security@integralis=
.com, including a copy of this message. Please then delete this email and d=
estroy any copies of it.<BR>
</FONT></CODE></BODY></HTML>

------=_NextPart_000_0017_01C030AD.72A16870--



From owner-dhcp-v6@bucknell.edu  Mon Oct  9 03:25:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29393;
	Mon, 9 Oct 2000 03:25:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e997NFb28527;
	Mon, 9 Oct 2000 03:23:15 -0400 (EDT)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e997NAb01759
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 03:23:10 -0400 (EDT)
Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132])
	by palrel3.hp.com (Postfix) with ESMTP id B5EFF619
	for <dhcp-v6@bucknell.edu>; Mon,  9 Oct 2000 00:23:07 -0700 (PDT)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id MAA21393 for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 12:51:57 +0530 (IST)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <39E172E2.1A494FB7@dce.india.hp.com>
Date: Mon, 09 Oct 2000 12:55:23 +0530
From: vijaya bhaskar <vijayak@dce.india.hp.com>
Organization: hp ISO
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.10 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Question on Reconfigure-init
Content-Type: multipart/alternative;
 boundary="------------25D4DFEE5C34895E2474E71E"
Reply-To: dhcp-v6@bucknell.edu
X-Sender: vijayak@india.hp.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


--------------25D4DFEE5C34895E2474E71E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If the purpose of Reconfigure and Reconfigure-init is going to be the
same ( whether its releasable resource or non- releasable resource,
reconfiguration is its purpose ), then why do we need two types of
messages for reconfiguration. Is there any specific reasons for having
two type of reconfiguration message.
Regards,
Vijay

--
     __            __
    /_/\          / /\       Vijaya Bhaskar A K
    \ \ \  __    / /  \      Hewlett Packard
     \ \ \/  \  / / /\ \     India Software Operations
      \ \  /\ \ \ \ \/ /     30, Cunningham Road
       \ \ \ \ \ \ \  /      Bangalore, India 560 052
        \ \ \ \/  \ \ \
         \ \ \     \ \ \     Phone: (91)(80)225 1554-1424
          \_\/      \_\/     Email: vijayak@india.hp.com



--------------25D4DFEE5C34895E2474E71E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<address>
If the purpose of Reconfigure and Reconfigure-init is going to be the same
( whether its releasable resource or non- releasable resource,&nbsp; reconfiguration
is its purpose ), then why do we need two types of messages for reconfiguration.
Is there any specific reasons for having two type of reconfiguration message.</address>

<address>
</address>

<address>
Regards,<br>
Vijay</address>

<address>
</address>

<pre>--&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; __&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; __
&nbsp;&nbsp;&nbsp; /_/\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; / /\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Vijaya Bhaskar A K
&nbsp;&nbsp;&nbsp; \ \ \&nbsp; __&nbsp;&nbsp;&nbsp; / /&nbsp; \&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hewlett Packard&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; \ \ \/&nbsp; \&nbsp; / / /\ \&nbsp;&nbsp;&nbsp;&nbsp; India Software Operations
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ \&nbsp; /\ \ \ \ \/ /&nbsp;&nbsp;&nbsp;&nbsp; 30, Cunningham Road
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ \ \ \ \ \ \&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bangalore, India 560 052
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ \ \ \/&nbsp; \ \ \&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ \ \&nbsp;&nbsp;&nbsp;&nbsp; \ \ \&nbsp;&nbsp;&nbsp;&nbsp; Phone: (91)(80)225 1554-1424
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \_\/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \_\/&nbsp;&nbsp;&nbsp;&nbsp; Email: vijayak@india.hp.com</pre>
&nbsp;</html>

--------------25D4DFEE5C34895E2474E71E--



From owner-dhcp-v6@bucknell.edu  Mon Oct  9 08:17:19 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02298;
	Mon, 9 Oct 2000 08:17:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99CEob17308;
	Mon, 9 Oct 2000 08:14:50 -0400 (EDT)
Received: from mailhost.ne.arris-i.com (abyss.arris-i.com [206.135.68.99])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e99CEib31868
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 08:14:44 -0400 (EDT)
Received: from arris-i.com (dhcp38-34.ne.arris-i.com [141.251.38.34])
	by mailhost.ne.arris-i.com (8.9.3/8.9.3) with ESMTP id IAA03783
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 08:03:10 -0400
Message-ID: <39E1B64D.C780D7D7@arris-i.com>
Date: Mon, 09 Oct 2000 08:13:01 -0400
From: David Hodgdon <David.Hodgdon@ARRIS-I.COM>
Reply-To: Paul Barker <paul.barker@INTEGRALIS.CO.UK>
Organization: Arris Interactive
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: UNSUBSCRIBE
Content-Type: multipart/alternative;
 boundary="------------255D847767E522DD03878AE6"
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


--------------255D847767E522DD03878AE6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit





--------------255D847767E522DD03878AE6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<style></style>
</head>
<body bgcolor="#FFFFFF">
&nbsp;
<br><tt><font size=+0></font></tt>&nbsp;
<br><tt><font size=+0></font></tt>&nbsp;
</body>
</html>

--------------255D847767E522DD03878AE6--



From owner-dhcp-v6@bucknell.edu  Mon Oct  9 08:41:07 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02807;
	Mon, 9 Oct 2000 08:41:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99CeYb28239;
	Mon, 9 Oct 2000 08:40:34 -0400 (EDT)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e99CeGb00234
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 08:40:17 -0400 (EDT)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000087674@fsnt.future.futsoft.com> for <dhcp-v6@bucknell.edu>;
 Mon, 09 Oct 2000 18:12:28 +0530
Received: from purushn.future.futsoft.com (purushn.future.futsoft.com [10.0.14.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA13414 for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 17:57:02 +0530
Received: by localhost with Microsoft MAPI; Mon, 9 Oct 2000 18:05:34 +0530
Message-Id: <01C0321B.851007E0.purushn@future.futsoft.com>
From: Purushothaman N <purushn@future.futsoft.com>
Reply-To: "purushn@future.futsoft.com" <purushn@future.futsoft.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: UNSUBSCRIBE
Date: Mon, 9 Oct 2000 18:05:32 +0530
Organization: Future Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN





From owner-dhcp-v6@bucknell.edu  Mon Oct  9 11:06:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05289;
	Mon, 9 Oct 2000 11:06:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99F3Ub29038;
	Mon, 9 Oct 2000 11:03:30 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e99F3Ib31095;
	Mon, 9 Oct 2000 11:03:18 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA24190; Mon, 9 Oct 2000 11:03:03 -0400 (EDT)
Message-Id: <4.3.1.2.20001009110235.00c1bb10@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 09 Oct 2000 11:05:20 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Mailing list admin
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Admin requests for the dhcp-v4@bucknell.ed and dhcp-v6@bucknell.edu mailing 
lists should now go to listproc@bucknell.edu

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct  9 15:38:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09184;
	Mon, 9 Oct 2000 15:38:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99Ja1b13013;
	Mon, 9 Oct 2000 15:36:01 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e99JZlb04625
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 15:35:47 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-108.ip.theriver.com [206.97.58.108]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e99JZRA13056; Mon, 9 Oct 2000 12:35:27 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e99JXKq00446; Mon, 9 Oct 2000 12:33:25 -0700 (MST)
Message-Id: <200010091933.e99JXKq00446@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: UNSUBSCRIBE 
In-Reply-To: Message from David Hodgdon <David.Hodgdon@ARRIS-I.COM> 
   of "Mon, 09 Oct 2000 08:13:01 -0400." <39E1B64D.C780D7D7@arris-i.com> 
Date: Mon, 09 Oct 2000 12:33:20 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


For those who want to unsubscribe, please contact
listproc@bucknell.edu and put "help" in the message body.   You can't
unsubscribe by sending a message to the mailing list with
"UNSUBSCRIBE" in the subject line.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Oct  9 15:52:16 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09403;
	Mon, 9 Oct 2000 15:52:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99Jpib07352;
	Mon, 9 Oct 2000 15:51:44 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e99JpXb10927
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 15:51:33 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01103 for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 15:51:16 -0400 (EDT)
Message-Id: <4.3.1.2.20001009154734.00c22220@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 09 Oct 2000 15:53:31 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Discussion thread summaries
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I'm writing up summaries of the discussion threads on issues from the 8/31 
design team phone call.  The ultimate goal of these summaries will be to 
confirm WG consensus on a specific resolution of each issue.  Each summary 
will include what I believe to be the ending point of each thread.  In 
cases where we reached a conclusion, I will confirm we have WG 
consensus.  In cases where there are remaining issues to resolve, I will 
summarize what we have agreed on and identify issues that are TBD.

We need to come to a conclusion and consensus about these issues as quicky 
as possible, so Mike, Jm and I can get the docs revved as quickly as 
possible...

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct  9 15:53:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09431;
	Mon, 9 Oct 2000 15:53:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99JrJb00351;
	Mon, 9 Oct 2000 15:53:19 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e99JrHb02889
	for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 15:53:17 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01335 for <dhcp-v6@bucknell.edu>; Mon, 9 Oct 2000 15:53:01 -0400 (EDT)
Message-Id: <4.3.1.2.20001009155342.00c51840@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 09 Oct 2000 15:55:17 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Discussion: client identifier
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Issue: Definition of "client identifier" for DHCPv6.

Ted initiated
the discussion with the following summary of issues:

	(a) Giving a DHCP client a unique identification that does
	    not change when network hardware changes
	(b) Providing a way to identify more than one instance of
	    usage (I called these identity associations in my message
	    about the DHCPv6 address model) within an individual client.
	(c) Providing a way for the server to tell that two identity
	    associations actually represent one client.
	(d) Providing a way to have a single authentication
	    key work with all of a client's identity associations.

Ted initially proposed a model in which every "identity association"
(IA) (this term is taken from our conversation about the DHCPv6 address
model; an IA is a set of IPv6 addresses and an associated identifier)
has a unique identifier.  An IA identifier is a tuple consisting of a
unique client identifier (UUID) and a modifier.  The client's UID
remains unchanged "forever", addressing issue (a).  All IAs from a single
DHCP client share the same UUID and have different modifiers.  Using
(UUID, modifier) to identify an IA addresses (b).  Because all
IAs from a single client share the same UUID, servers can identify
different IAs from the same client (c).  Finally, by basing
authentication on just the UUID, all messages about IAs from a single
client can be authenticated using the same key.

The discussion settled on calling the "modifier" a "binding-id", which
is an opaque number uniquely identifying an IA from a DHCP client.
The client will likely manage binding-ids over time so that the
addresses in an IA need not be unnecessarily replaced (that is, on a
specific host, if binding-id 1 identifies an IA from subnet A and
binding-id 2 identifies an IA from subnet B, the client will not
switch binding-id 1 to subnet B and vice versa).  If a client cannot
manage binding-ids, it will indicate to the server that it has no
state about previous binding-ids.


Summary: IAs will be identfied by a tuple: (UUID, binding-id).  UUID
is a unique identifier for a DHCP client.  All IAs from one DHCP
client share the same UUID.  A binding-id is an opaque
value uniquely identifying an IA within a client.  The client is
responsible for managing binding-ids and the protocol makes no
statement about the way in which binding-ids are formed.

TBD: Size and shape (number of bits, fixed or variable length) of UUID
and binding-id.



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 12:05:08 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06969;
	Tue, 10 Oct 2000 12:05:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AG2Db01373;
	Tue, 10 Oct 2000 12:02:13 -0400 (EDT)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AG26b00735
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:02:06 -0400 (EDT)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA29648
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:01:48 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA26452
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:01:49 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA25159 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:01:40 -0400
Message-Id: <200010101601.MAA25159@rotala.raleigh.ibm.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> 
   of "Mon, 09 Oct 2000 15:55:17 EDT." <4.3.1.2.20001009155342.00c51840@funnel.cisco.com> 
Date: Tue, 10 Oct 2000 12:01:40 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> Summary: IAs will be identfied by a tuple: (UUID, binding-id).  UUID
> is a unique identifier for a DHCP client.

How are UUIDs assigned? How does a client determine its UUID? I'm
thinking in particular of:

1) machines that are plugged into the network for the first time
2) machines that have no stable storage, and thus can't store
   configuration information across system restarts.

As much as using a MAC has its disadvantages, it does have the
advantage that every interface has one, and its pretty much globally
unique. If one doesn't use the MAC, what will be used instead?

Or is the thinking that the default UUID for a node will be based on
the MAC address? What if that network interface is then taken out of
one machine and put into another? How will conflicts be resolved if
two machines create UUIDs derived from the same MAC address?

Thomas



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 12:13:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07163;
	Tue, 10 Oct 2000 12:13:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AGBOb12263;
	Tue, 10 Oct 2000 12:11:24 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AGBBb21989
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:11:11 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23124 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:10:55 -0400 (EDT)
Message-Id: <4.3.1.2.20001010115937.00b39a90@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 12:03:44 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Discussion: sharing options/extensions between DHCPv4 and
  DHCPv6
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Issue: 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).

Summary: Bernie described certain DHCPv4 options as carrying
version-independent parameters such as domain names and URLs.  Any
option carrying an IP address would *not* fit into this category.
Such options would use the same option number and data format for both
DHCpv4 and DHCPv6 (although the option format would be different to
allow for 16-bit option codes and lengths in DHCPv6).

Current options that fall into this category would be described in a
single document (supplementary to and separate from the DHCCPv6
spec).  A new options that fits into this category would include a
statement that it is defined for both DHCPv4 and DHCPv6.  IANA would
be informed to assign option code numbers for these options in the
1-127 range for compatibility with DHCPv4.  DHCPv6 option codes in the
range 1-127 will be reserved for options defined for both protocols.



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 12:18:32 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07264;
	Tue, 10 Oct 2000 12:18:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AGHGb28253;
	Tue, 10 Oct 2000 12:17:16 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AGH9b02717
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:17:09 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2JF4>; Tue, 10 Oct 2000 12:16:53 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607060@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier
Date: Tue, 10 Oct 2000 12:16:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

We have discussed this issue on the mailing list and I'm sure Ralph will get
around to publishing the discussion/summary soon. I suspect that there are
still several open issues related to this.

For the summary that Ralph wrote up, saying that we'll be using these two
items is correct. But a further summary of what these two items are is
hopefully coming.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Tuesday, October 10, 2000 12:02 PM
To: DHCPv6 discussion list
Subject: Re: Discussion: client identifier


> Summary: IAs will be identfied by a tuple: (UUID, binding-id).  UUID
> is a unique identifier for a DHCP client.

How are UUIDs assigned? How does a client determine its UUID? I'm
thinking in particular of:

1) machines that are plugged into the network for the first time
2) machines that have no stable storage, and thus can't store
   configuration information across system restarts.

As much as using a MAC has its disadvantages, it does have the
advantage that every interface has one, and its pretty much globally
unique. If one doesn't use the MAC, what will be used instead?

Or is the thinking that the default UUID for a node will be based on
the MAC address? What if that network interface is then taken out of
one machine and put into another? How will conflicts be resolved if
two machines create UUIDs derived from the same MAC address?

Thomas



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 14:21:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09702;
	Tue, 10 Oct 2000 14:21:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AIIKb11870;
	Tue, 10 Oct 2000 14:18:20 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AII6b31697
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:18:07 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11101 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:17:51 -0400 (EDT)
Message-Id: <4.3.1.2.20001010141001.00b1d780@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 14:20:02 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: Discussion: client identifier
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607060@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 12:16 PM 10/10/00 -0400, you wrote:
>We have discussed this issue on the mailing list and I'm sure Ralph will get
>around to publishing the discussion/summary soon. I suspect that there are
>still several open issues related to this.

Actually, what I published was what I took to be the resolution of the 
issue as it was developed in the course of the mailing list discussion.  I 
don't intend to summarize the discussion itself.  I mentioned an open 
issue: the size and shape of the UID and binding-id are TBD.  Thomas 
brought up another open issue: what does a client use as its UUID.

>For the summary that Ralph wrote up, saying that we'll be using these two
>items is correct. But a further summary of what these two items are is
>hopefully coming.

I just reviewed the discussion - as far as I can tell, we decided on the 
two part identifier, (UUID, binding-id), and defined the binding-id as an 
opaque value chosen by the client.  I don't think we answered either of the 
two open issues listed above.  So, we need to resolve the two issues or 
document them as still open in the next rev of the spec...

- Ralph



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 14:34:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10010;
	Tue, 10 Oct 2000 14:34:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AIY7b11697;
	Tue, 10 Oct 2000 14:34:07 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AIXub21676
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:33:56 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a3.pm3-24.theriver.com [206.102.192.19]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9AIXYL16459 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 11:33:34 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e9AIVGw01711 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 11:31:21 -0700 (MST)
Message-Id: <200010101831.e9AIVGw01711@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: sharing options/extensions between DHCPv4 and DHCPv6 
In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> 
   of "Tue, 10 Oct 2000 12:03:44 -0400." <4.3.1.2.20001010115937.00b39a90@funnel.cisco.com> 
Date: Tue, 10 Oct 2000 11:31:16 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Summary: Bernie described certain DHCPv4 options as carrying
> version-independent parameters such as domain names and URLs.  Any
> option carrying an IP address would *not* fit into this category.
> Such options would use the same option number and data format for both
> DHCpv4 and DHCPv6 (although the option format would be different to
> allow for 16-bit option codes and lengths in DHCPv6).

I thought we were going to keep the options that have the same meaning
but whose contents are IPv6 addresses instead of IPv4 addresses the
same as well.   Is there any reason not to?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 14:47:07 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10431;
	Tue, 10 Oct 2000 14:47:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AIkdb31383;
	Tue, 10 Oct 2000 14:46:39 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AIkPb13585
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:46:25 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA15554 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:46:10 -0400 (EDT)
Message-Id: <4.3.1.2.20001010144220.00b198f0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 14:48:27 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: sharing options/extensions between DHCPv4 and
  DHCPv6 
In-Reply-To: <200010101831.e9AIVGw01711@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <rdroms@cisco.com>
 <4.3.1.2.20001010115937.00b39a90@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:31 AM 10/10/00 -0700, Ted Lemon wrote:

> > Summary: Bernie described certain DHCPv4 options as carrying
> > version-independent parameters such as domain names and URLs.  Any
> > option carrying an IP address would *not* fit into this category.
> > Such options would use the same option number and data format for both
> > DHCpv4 and DHCPv6 (although the option format would be different to
> > allow for 16-bit option codes and lengths in DHCPv6).
>
>I thought we were going to keep the options that have the same meaning
>but whose contents are IPv6 addresses instead of IPv4 addresses the
>same as well.   Is there any reason not to?

I thought we had discussed that as well, but I couldn't find any reference 
to the idea in the archive - of course, I may have missed it.

In any event, retaining those options that carry IP addresses as sell makes 
sense to me.  I can imagine adding some text somewhere to the effect that 
the following options carry IPv4 addresses  whn carried in a DHCPv4 message 
and IPv6 addresses when carried in an IPv6 message (and be sure to fix the 
len field to be 4*n or 16*n)...

- Ralph



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 14:47:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10449;
	Tue, 10 Oct 2000 14:47:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AIkZb24069;
	Tue, 10 Oct 2000 14:46:35 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AIkNb10927
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:46:23 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2JNT>; Tue, 10 Oct 2000 14:46:07 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607062@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: sharing options/extensions between DHCPv4 and DHC
	Pv6
Date: Tue, 10 Oct 2000 14:46:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

My proposal was not to use these same options number - since the data is
different. Reusing the "domain name" option is fine since the option is
"identical". But, reusing the default router option with an IPv6 instead of
IPv4 option is, IMHO, not fine. So, I would not be for this.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Tuesday, October 10, 2000 2:31 PM
To: DHCPv6 discussion list
Subject: Re: Discussion: sharing options/extensions between DHCPv4 and
DHCPv6



> Summary: Bernie described certain DHCPv4 options as carrying
> version-independent parameters such as domain names and URLs.  Any
> option carrying an IP address would *not* fit into this category.
> Such options would use the same option number and data format for both
> DHCpv4 and DHCPv6 (although the option format would be different to
> allow for 16-bit option codes and lengths in DHCPv6).

I thought we were going to keep the options that have the same meaning
but whose contents are IPv6 addresses instead of IPv4 addresses the
same as well.   Is there any reason not to?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:01:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10888;
	Tue, 10 Oct 2000 15:01:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AItWb23150;
	Tue, 10 Oct 2000 14:55:32 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AItPb31250
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:55:25 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2J31>; Tue, 10 Oct 2000 14:55:10 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607063@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier
Date: Tue, 10 Oct 2000 14:55:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

The binding-id was discussed several times to be 8 or 16-bit value. It was
probably in the earlier context of using 3-tuple (client identifier,
interface identifier, and binding identifier) that this size was discussed.

Personally, I like the idea of an opaque value (from 0 to 16 or so bytes)
but that wasn't liked by others because it made hashing and lookups more of
a problem.

Regarding the UUID, there were some discussions about that as well - at
least how to create it. Length again might best be variable (up to some
upper bound). I think the format should be something like a byte or word for
a type of UUID, followed by one or more fields depending on how the UUID was
generated. For example, if a serial number were used, these fields might
consist of a hardware type id followed by the serial number. Now, of course,
it would be best to use some sort of hash over this such that the data is
not meaningful to anyone to pull out these values easily.

But, agreed we need more detailed discussion to resolve both of these issues
- UUID and binding identifier.

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Tuesday, October 10, 2000 2:20 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier


At 12:16 PM 10/10/00 -0400, you wrote:
>We have discussed this issue on the mailing list and I'm sure Ralph will
get
>around to publishing the discussion/summary soon. I suspect that there are
>still several open issues related to this.

Actually, what I published was what I took to be the resolution of the 
issue as it was developed in the course of the mailing list discussion.  I 
don't intend to summarize the discussion itself.  I mentioned an open 
issue: the size and shape of the UID and binding-id are TBD.  Thomas 
brought up another open issue: what does a client use as its UUID.

>For the summary that Ralph wrote up, saying that we'll be using these two
>items is correct. But a further summary of what these two items are is
>hopefully coming.

I just reviewed the discussion - as far as I can tell, we decided on the 
two part identifier, (UUID, binding-id), and defined the binding-id as an 
opaque value chosen by the client.  I don't think we answered either of the 
two open issues listed above.  So, we need to resolve the two issues or 
document them as still open in the next rev of the spec...

- Ralph



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:02:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10911;
	Tue, 10 Oct 2000 15:02:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AItEb23679;
	Tue, 10 Oct 2000 14:55:14 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AIt0b07990
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:55:00 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a3.pm3-24.theriver.com [206.102.192.19]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9AIscL16535 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 11:54:38 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e9AIqLw02013 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 11:52:21 -0700 (MST)
Message-Id: <200010101852.e9AIqLw02013@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Tue, 10 Oct 2000 14:20:02 -0400." <4.3.1.2.20001010141001.00b1d780@mail.bucknell.edu> 
Date: Tue, 10 Oct 2000 11:52:21 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I just reviewed the discussion - as far as I can tell, we decided on the 
> two part identifier, (UUID, binding-id), and defined the binding-id as an 
> opaque value chosen by the client.  I don't think we answered either of the 
> two open issues listed above.  So, we need to resolve the two issues or 
> document them as still open in the next rev of the spec...

Ralph, we have a pretty clear specification for how a UUID is defined
that Bernie sent to the mailing list.   I certainly agree that this is
the right thing to do, and other than one clarification that someone
(Erik Nordmark?) made, I think it works and we should use it.   I
thought that *was* the consensus!   :'}

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:02:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10912;
	Tue, 10 Oct 2000 15:02:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AIvqb06123;
	Tue, 10 Oct 2000 14:57:52 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AIvnb13598
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 14:57:49 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2J3H>; Tue, 10 Oct 2000 14:57:34 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607064@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: sharing options/extensions between DHCPv4 and DHC
	Pv6
Date: Tue, 10 Oct 2000 14:57:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

As I replied separately, I don't agree with reusing these.

One reason is that suppose you had a single repository (LDAP?) where all of
the options data was stored. If you let a single option have two possible
values, it just makes configuration of a the data (in this storage
repository or in a server that implements both DHCPv4 and DHCPv6) much more
difficult.

One option (one value) can store things like domain names and URLs. But, the
same is not true when the data "inside" the option can have two different
values.

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Tuesday, October 10, 2000 2:48 PM
To: DHCPv6 discussion list
Subject: Re: Discussion: sharing options/extensions between DHCPv4 and
DHCPv6


At 11:31 AM 10/10/00 -0700, Ted Lemon wrote:

> > Summary: Bernie described certain DHCPv4 options as carrying
> > version-independent parameters such as domain names and URLs.  Any
> > option carrying an IP address would *not* fit into this category.
> > Such options would use the same option number and data format for both
> > DHCpv4 and DHCPv6 (although the option format would be different to
> > allow for 16-bit option codes and lengths in DHCPv6).
>
>I thought we were going to keep the options that have the same meaning
>but whose contents are IPv6 addresses instead of IPv4 addresses the
>same as well.   Is there any reason not to?

I thought we had discussed that as well, but I couldn't find any reference 
to the idea in the archive - of course, I may have missed it.

In any event, retaining those options that carry IP addresses as sell makes 
sense to me.  I can imagine adding some text somewhere to the effect that 
the following options carry IPv4 addresses  whn carried in a DHCPv4 message 
and IPv6 addresses when carried in an IPv6 message (and be sure to fix the 
len field to be 4*n or 16*n)...

- Ralph



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:12:35 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11139;
	Tue, 10 Oct 2000 15:12:33 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AJAbb02098;
	Tue, 10 Oct 2000 15:10:38 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AJANb11627
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:10:23 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19095 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:10:06 -0400 (EDT)
Message-Id: <4.3.1.2.20001010150249.00b18d50@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 15:12:23 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: Discussion: client identifier
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607063@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 02:55 PM 10/10/00 -0400, Bernie wrote:
>The binding-id was discussed several times to be 8 or 16-bit value. It was
>probably in the earlier context of using 3-tuple (client identifier,
>interface identifier, and binding identifier) that this size was discussed.

Right - I read the final description as "an opaque value of undetermined 
size" and used that definition in the summary.

>Regarding the UUID, there were some discussions about that as well - at
>least how to create it. Length again might best be variable (up to some
>upper bound).

In his original message, Ted mentioned the PXE algorithm, but I can't find 
any subsequent reference to a mechanism for specifying a UUID.  So I view 
that issue as open.  We also discussed variable versus fixed length UID, 
again, as far as I know, without consensus on an answer.

>  I think the format should be something like a byte or word for
>a type of UUID, followed by one or more fields depending on how the UUID was
>generated. For example, if a serial number were used, these fields might
>consist of a hardware type id followed by the serial number. Now, of course,
>it would be best to use some sort of hash over this such that the data is
>not meaningful to anyone to pull out these values easily.
>
>But, agreed we need more detailed discussion to resolve both of these issues
>- UUID and binding identifier.

Yup...

- Ralph




From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:15:07 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11216;
	Tue, 10 Oct 2000 15:15:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AJ37b14605;
	Tue, 10 Oct 2000 15:03:07 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AJ32b24220
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:03:03 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a3.pm3-24.theriver.com [206.102.192.19]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9AJ2cL16562 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:02:38 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e9AJ0Mw02139 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:00:22 -0700 (MST)
Message-Id: <200010101900.e9AJ0Mw02139@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: sharing options/extensions between DHCPv4 and DHC Pv6 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Tue, 10 Oct 2000 14:46:06 -0400." <63D30D6E10CFD11190A90000F805FE8603607062@lespaul.process.com> 
Date: Tue, 10 Oct 2000 12:00:22 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> My proposal was not to use these same options number - since the data is
> different. Reusing the "domain name" option is fine since the option is
> "identical". But, reusing the default router option with an IPv6 instead of
> IPv4 option is, IMHO, not fine. So, I would not be for this.

There are so few options for which the contents are exactly identical
that I don't think there's any purpose in specifying this if we
exclude options containing IP addresses.   If we are going to exclude
those, I would say just let the two option code spaces be completely
orthogonal.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:17:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11284;
	Tue, 10 Oct 2000 15:17:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AJGEb06994;
	Tue, 10 Oct 2000 15:16:14 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AJFfb23566
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:15:42 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19873 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:15:21 -0400 (EDT)
Message-Id: <4.3.1.2.20001010151312.00b1a960@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 15:17:35 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010101852.e9AIqLw02013@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20001010141001.00b1d780@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:52 AM 10/10/00 -0700, Ted Lemon wrote:

> > I just reviewed the discussion - as far as I can tell, we decided on the
> > two part identifier, (UUID, binding-id), and defined the binding-id as an
> > opaque value chosen by the client.  I don't think we answered either of 
> the
> > two open issues listed above.  So, we need to resolve the two issues or
> > document them as still open in the next rev of the spec...
>
>Ralph, we have a pretty clear specification for how a UUID is defined
>that Bernie sent to the mailing list.   I certainly agree that this is
>the right thing to do, and other than one clarification that someone
>(Erik Nordmark?) made, I think it works and we should use it.   I
>thought that *was* the consensus!   :'}

I'm sorry to be difficult, but I can find neither Bernie's final 
description nor Erik's clarification.  Can you point me at those 
words?  Thanks...

- Ralph




From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:22:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11437;
	Tue, 10 Oct 2000 15:22:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AJMEb18158;
	Tue, 10 Oct 2000 15:22:14 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AJLxb19961
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:22:00 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20681 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:21:41 -0400 (EDT)
Message-Id: <4.3.1.2.20001010152057.00ae4710@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 15:23:55 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010101852.e9AIqLw02013@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20001010141001.00b1d780@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:52 AM 10/10/00 -0700, you wrote:

> > I just reviewed the discussion - as far as I can tell, we decided on the
> > two part identifier, (UUID, binding-id), and defined the binding-id as an
> > opaque value chosen by the client.  I don't think we answered either of 
> the
> > two open issues listed above.  So, we need to resolve the two issues or
> > document them as still open in the next rev of the spec...
>
>Ralph, we have a pretty clear specification for how a UUID is defined
>that Bernie sent to the mailing list.

I discovered the source of my confusion - Bernie's spec appeared in the 
address model thread, not in the client identifier thread.  I wrote up the 
summary with my "thread-blinders" on.

So, here's Bernie's specification:

1) If a client has previously stored a unique identifier in stable storage,
it MUST use this for all its interfaces.
2) If a client has unique identifying information (such as a serial number)
that it can use as a unique identifier, it MUST use this (after storing it
in stable storage if possible).
3) If a client does not have unique identifying information and it has
stable storage, it should generate a unique identifier by combining the
link-layer address of one or more network interfaces, padded with zeros at
the end to a total length of sixteen bytes, with a randomly generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to produce a
unique identifier, and should store this identifier in stable storage.
4) Otherwise, the client must generate a unique identifier in a way that the
same value is likely to be generated each time it boots, such as by using
the link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces.

And Erik's follow up:

 > 2) If a client has unique identifying information (such as a serial number)
 > that it can use as a unique identifier, it MUST use this (after storing it
 > in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.




From owner-dhcp-v6@bucknell.edu  Tue Oct 10 15:28:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11539;
	Tue, 10 Oct 2000 15:27:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AJROb18157;
	Tue, 10 Oct 2000 15:27:24 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AJRLb07051
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 15:27:21 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a3.pm3-24.theriver.com [206.102.192.19]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9AJQxL16635 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:26:59 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e9AJOfw02531 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 12:24:41 -0700 (MST)
Message-Id: <200010101924.e9AJOfw02531@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Tue, 10 Oct 2000 15:17:35 -0400." <4.3.1.2.20001010151312.00b1a960@mail.bucknell.edu> 
Date: Tue, 10 Oct 2000 12:24:41 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I'm sorry to be difficult, but I can find neither Bernie's final 
> description nor Erik's clarification.  Can you point me at those 
> words?  Thanks...

No problem!   :')

				_MelloN_

------- Forwarded Messages

Message-ID: <63D30D6E10CFD11190A90000F805FE8603606FDD@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 2 Oct 2000 11:02:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I do think the wording below will need some rework. For example: "Clients
that have no stable storage MUST use the link-layer address of one of their
network interfaces as the client identifer, and MUST use the same client
identifier for all of their interfaces."

If a client has other unique identifying information, such as a unique
serial number burned into memory it should use that and not any network
interface information. Therefore the "MUST" MUST be removed or changed to be
conditional.

I believe the rules should be:

1) If a client has previously stored a unique identifier in stable storage,
it MUST use this for all its interfaces.
2) If a client has unique identifying information (such as a serial number)
that it can use as a unique identifier, it MUST use this (after storing it
in stable storage if possible).
3) If a client does not have unique identifying information and it has
stable storage, it should generate a unique identifier by combining the
link-layer address of one or more network interfaces, padded with zeros at
the end to a total length of sixteen bytes, with a randomly generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to produce a
unique identifier, and should store this identifier in stable storage.
4) Otherwise, the client must generate a unique identifier in a way that the
same value is likely to be generated each time it boots, such as by using
the link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces.

- - Bernie

- -----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Thursday, September 28, 2000 9:54 PM
To: DHCPv6 discussion list
Cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal...



> How do we verify that a clients IA is in fact unique if it don't verify
> that with other clients?
>  a) on the link best case
>  b) with the servers dhcp domain?

The schemes that have been proposed for coming up with UUIDs
(Universally Unique Identifiers) rely more on reducing the chance of
collision to ridiculously low amounts than they do on any mechanical
process of guaranteeing that the identifier is unique.  I am pretty
sure that Windows has a UUID that is generated this way.   Computers
with serial numbers could use a vendor name plus the serial number.

I think the language in the draft should say something like "DHCP
clients SHOULD use a client identifier that will not vary as a result
of changes in network hardware and will be consistent between network
interfaces.  DHCP clients SHOULD NOT use the link-layer address of a
network interface by itself as a client identifier, but SHOULD instead
use some other identifier that is known to be globally unique - for
example, a combination of the CPU's serial number and manufacturer's
registered domain name.   DHCP clients that have no unique identifier
other than the link-layer address SHOULD combine the link-layer
address of one or more network interfaces, padded with zeros at the
end to a total length of sixteen bytes, with a randomly-generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to
produce a unique identifier, and should store this identifier in
stable storage.   Clients that have no stable storage MUST use the
link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces."

This is rather convoluted, but I think it covers all the possible
cases where one could get into trouble.   The only case where we could
get into trouble is if two clients connected to the same link use the
HASH (pad16 (link-layer-addr) + random4) and wind up producing the
same hash value.   The reason for using the highly-structured formula
for producing the hash is to make this vanishingly unlikely, but I'm
not a crypto-geek, so I may have gotten it wrong.

We could also require the client to identify which of the algorithms
it is using in the first byte of the identifier, which would avoid
stupid collisions due to differing algorithms.

The language should also probably be made more readable - I'd be happy
to do this if people think this is a good set of methods to use to
generate the client identifier.

BTW, I am just talking about how to generate the common per-client
part of the identifier.  We also talked about the client combining its
per-client identifier with an additional per-instance identifier so as
to uniquely identify an address association, so that the client could
have more than one address association - e.g., for application-
specific situations or for clients supporting more than one interface,
or using DHCP to manage a care-of address as well as a home address.

			       _MelloN_


------- Message 2

Date: Wed, 4 Oct 2000 18:34:53 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: RE: DHCPv6 address model proposal...
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <63D30D6E10CFD11190A90000F805FE8603606FDD@lespaul.process.com>
Message-ID: <Roam.SIMC.2.0.6.970709693.5419.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Bernie,

 > 2) If a client has unique identifying information (such as a serial number)
> that it can use as a unique identifier, it MUST use this (after storing it
> in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.

   Erik


------- End of Forwarded Messages



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 16:46:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13017;
	Tue, 10 Oct 2000 16:45:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AKh0b02837;
	Tue, 10 Oct 2000 16:43:00 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AKgwb12462
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 16:42:58 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02664 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 16:42:39 -0400 (EDT)
Message-Id: <4.3.1.2.20001010163822.00b0e790@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 16:42:37 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010101924.e9AJOfw02531@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20001010151312.00b1a960@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

OK, so here's the "client identifier" summary, extended to include the 
details of UUID generation
Issue: Definition of "client identifier" for DHCPv6.

Ted initiated
the discussion with the following summary of issues:

	(a) Giving a DHCP client a unique identification that does
	    not change when network hardware changes
	(b) Providing a way to identify more than one instance of
	    usage (I called these identity associations in my message
	    about the DHCPv6 address model) within an individual client.
	(c) Providing a way for the server to tell that two identity
	    associations actually represent one client.
	(d) Providing a way to have a single authentication
	    key work with all of a client's identity associations.

Ted initially proposed a model in which every "identity association"
(IA) (this term is taken from our conversation about the DHCPv6
address model; an IA is a set of IPv6 addresses and an associated
identifier) has a unique identifier.  An IA identifier is a tuple
consisting of a unique client identifier (UUID) and a modifier.  The
client's UID remains unchanged "forever", addressing issue (a).  All
IAs from a single DHCP client share the same UUID and have different
modifiers.  Using (UUID, modifier) to identify an IA addresses (b).
Because all IAs from a single client share the same UUID, servers can
identify different IAs from the same client (c).  Finally, by basing
authentication on just the UUID, all messages about IAs from a single
client can be authenticated using the same key.

The discussion settled on calling the "modifier" a "binding-id", which
is an opaque number uniquely identifying an IA from a DHCP client.
The client will likely manage binding-ids over time so that the
addresses in an IA need not be unnecessarily replaced (that is, on a
specific host, if binding-id 1 identifies an IA from subnet A and
binding-id 2 identifies an IA from subnet B, the client will not
switch binding-id 1 to subnet B and vice versa).  If a client cannot
manage binding-ids, it will indicate to the server that it has no
state about previous binding-ids.


Summary: IAs will be identified by a tuple: (UUID, binding-id).  UUID
is a unique identifier for a DHCP client.  All IAs from one DHCP
client share the same UUID.  A binding-id is an opaque value uniquely
identifying an IA within a client.  The client is responsible for
managing binding-ids and the protocol makes no statement about the way
in which binding-ids are formed.

The rules for selecting a UUID are:

1) If a client has previously stored a unique identifier in stable
    storage, it MUST use this for all its interfaces.

2) If a client has unique identifying information (such as a serial
    number) that it can use as a unique identifier, it MUST use this
    (after storing it in stable storage if possible).  For this to
    produce unique numbers the spec must identify the number
    space. Otherwise two boxes made by two different vendors might both
    have serial number 17.

3) If a client does not have unique identifying information and it has
    stable storage, it should generate a unique identifier by combining
    the link-layer address of one or more network interfaces, padded
    with zeros at the end to a total length of sixteen bytes, with a
    randomly generated four-byte quantity, and compute an MD5 (SHA?)
    hash over this to produce a unique identifier, and should store
    this identifier in stable storage.

4) Otherwise, the client must generate a unique identifier in a way
    that the same value is likely to be generated each time it boots,
    such as by using the link-layer address of one of their network
    interfaces as the client identifier, and MUST use the same client
    identifier for all of their interfaces.

We have one suggestion for the format of a UUID: Length again might
best be variable (up to some upper bound). I think the format should
be something like a byte or word for a type of UUID, followed by one
or more fields depending on how the UUID was generated. For example,
if a serial number were used, these fields might consist of a hardware
type id followed by the serial number. Now, of course, it would be
best to use some sort of hash over this such that the data is not
meaningful to anyone to pull out these values easily.

TBD: Size and shape (number of bits, fixed or variable length) of UUID
and binding-id.



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 17:04:58 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13291;
	Tue, 10 Oct 2000 17:04:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AL46b03299;
	Tue, 10 Oct 2000 17:04:06 -0400 (EDT)
Received: from mail.ultradns.com ([64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AL3ob31424
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 17:03:50 -0400 (EDT)
Received: (qmail 21990 invoked from network); 10 Oct 2000 21:03:49 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 10 Oct 2000 21:03:49 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: sharing options/extensions between DHCPv4 and DHC Pv6 
Date: Tue, 10 Oct 2000 14:03:48 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNGEFOCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200010101900.e9AJ0Mw02139@grosse.bisbee.fugue.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


[Bernie]
> > My proposal was not to use these same options number - since the data is
> > different. Reusing the "domain name" option is fine since the option is
> > "identical". But, reusing the default router option with an
> IPv6 instead of
> > IPv4 option is, IMHO, not fine. So, I would not be for this.
>

[Ted]
> There are so few options for which the contents are exactly identical
> that I don't think there's any purpose in specifying this if we
> exclude options containing IP addresses.   If we are going to exclude
> those, I would say just let the two option code spaces be completely
> orthogonal.
>

...I agree: if and only if the format of the option, as well as the
interpretation of values is identical should we reuse the option code value,
and maybe even the option name to avoid confusion about the interpretation
of the data values...

--Barr



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 17:07:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13425;
	Tue, 10 Oct 2000 17:07:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9AL70b32404;
	Tue, 10 Oct 2000 17:07:00 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9AL6ob30624
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 17:06:50 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA05760 for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 17:06:32 -0400 (EDT)
Message-Id: <4.3.1.2.20001010165603.00b0db50@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 10 Oct 2000 17:08:46 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9,
  18 on Conference Call Agenda)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Issue: We raised several issues in the area of reconfiguration.  My notes 
are a little unclear about where we had agreement during the design team 
phone call.  In any event, let me try to summarize what I've been able to 
extract from the mailing list discussion:

YES     18. Simplify reconfiguration; Use DHCPv4-style reconfiguration

My notes from the phone call show agreement during the phone call for 
incorporating DHCPv4-style reconfiguration in DHCpv6.  There was one 
dissenting opinion during the mailing list discussion.  I read consensus as 
incorporating DHCPv4-style reconfiguration as a baseline, with the 
possibility of including additional functions such as use of multicast.

         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.
         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?

I didn't see much discussion of these two items and I don't see that we 
have consensus on resolution.

BERNIE  -  Implement multicast reconfigure?

I read consensus for support of multicast reconfigure.

TBD: Consensus on issues 8 and 9; detailed design for multicast reconfigure.



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 17:29:27 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13790;
	Tue, 10 Oct 2000 17:29:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9ALQhb30104;
	Tue, 10 Oct 2000 17:26:43 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9ALQXb20350
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 17:26:33 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2JXA>; Tue, 10 Oct 2000 17:26:17 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607065@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier
Date: Tue, 10 Oct 2000 17:26:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I believe there was one additional clarification, perhaps by Thomas but I
could be wrong ... and that was to use a hash or some other encryption
method on the various techniques of creating the UUID to reduce the
likelyhood that any of the information could be used by someone seeing the
packets. The idea is that the value is unique to a client but should not be
usable to derive anything meaningful about the client.

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Tuesday, October 10, 2000 3:24 PM
To: DHCPv6 discussion list
Subject: Re: Discussion: client identifier


At 11:52 AM 10/10/00 -0700, you wrote:

> > I just reviewed the discussion - as far as I can tell, we decided on the
> > two part identifier, (UUID, binding-id), and defined the binding-id as
an
> > opaque value chosen by the client.  I don't think we answered either of 
> the
> > two open issues listed above.  So, we need to resolve the two issues or
> > document them as still open in the next rev of the spec...
>
>Ralph, we have a pretty clear specification for how a UUID is defined
>that Bernie sent to the mailing list.

I discovered the source of my confusion - Bernie's spec appeared in the 
address model thread, not in the client identifier thread.  I wrote up the 
summary with my "thread-blinders" on.

So, here's Bernie's specification:

1) If a client has previously stored a unique identifier in stable storage,
it MUST use this for all its interfaces.
2) If a client has unique identifying information (such as a serial number)
that it can use as a unique identifier, it MUST use this (after storing it
in stable storage if possible).
3) If a client does not have unique identifying information and it has
stable storage, it should generate a unique identifier by combining the
link-layer address of one or more network interfaces, padded with zeros at
the end to a total length of sixteen bytes, with a randomly generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to produce a
unique identifier, and should store this identifier in stable storage.
4) Otherwise, the client must generate a unique identifier in a way that the
same value is likely to be generated each time it boots, such as by using
the link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces.

And Erik's follow up:

 > 2) If a client has unique identifying information (such as a serial
number)
 > that it can use as a unique identifier, it MUST use this (after storing
it
 > in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 17:34:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13890;
	Tue, 10 Oct 2000 17:34:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9ALY7b03673;
	Tue, 10 Oct 2000 17:34:07 -0400 (EDT)
Received: from mail.ultradns.com ([64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9ALXvb28803
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 17:33:57 -0400 (EDT)
Received: (qmail 22841 invoked from network); 10 Oct 2000 21:33:55 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 10 Oct 2000 21:33:55 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier 
Date: Tue, 10 Oct 2000 14:33:54 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNGEFPCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <4.3.1.2.20001010152057.00ae4710@mail.bucknell.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> For this to produce unique numbers you need to identify the number space
> as part of the I-D. Otherwise two boxes made by two different vendors
> might both have serial number 17.
>
>

...I'd be reluctant to specify the algorithm too closely:  better to specify
a uniform format (that is, minimum length) and desirable properties (such as
cryptographic strength), but to leave it at that...

One of the problems with the v4 spec is that the suggested method for
generating client identifiers leads to implementation issues when the NIC is
changed, and I'd like to avoid that again.

I doubt it is possible to guarantee that UUIDs don't collide, so a server
implementation would be required to have some process for dealing with
collisions, regardless of how well-specified the algorithm might be.

--Barr



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 21:56:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17647;
	Tue, 10 Oct 2000 21:56:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9B1sEb23261;
	Tue, 10 Oct 2000 21:54:14 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9B1s2b03176
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 21:54:02 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id VAA01737
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 21:53:12 -0400
Message-Id: <200010110153.VAA01737@hygro.adsl.duke.edu>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: Message from "Barr Hibbs" <rbhibbs@ultraDNS.com> 
   of "Tue, 10 Oct 2000 14:33:54 PDT." <JCELKJCFMDGAKJCIGGPNGEFPCIAA.rbhibbs@ultraDNS.com> 
Date: Tue, 10 Oct 2000 21:53:12 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> One of the problems with the v4 spec is that the suggested method for
> generating client identifiers leads to implementation issues when the NIC is
> changed, and I'd like to avoid that again.

There is also a different issue, one that concerns me somewhat, though
I'm not quite sure how much. If the client identifier is generated
from the MAC on an interface, and that gets saved in stable storage
(and reused from that point on per rule 1), there is an chance of
collisions occuring when the interface get moved to a different
machine, which subsequently generates a client indentifer using the
same algorithm. ONe is relying on the "add a random component" part of
the algorithm to generate good randomness. Maybe we can do that, but I
am somewhat concerned that this will not be robust enough in practice.

We really want the vast majority of client IDs to be generated by the
device maker at manufacture time (i.e, vendor ID plus serial
number). Is this something that we are confident can be done today on
effectively all devices?

> I doubt it is possible to guarantee that UUIDs don't collide, so a server
> implementation would be required to have some process for dealing with
> collisions, regardless of how well-specified the algorithm might be.

If there is a collision, what do you propose the server do? Seems to
me that it has no way of distinguishing between the case where the
same node is asking for different things (at different times) vs. two
different nodes asking for information.

Thomas



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 23:24:36 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19295;
	Tue, 10 Oct 2000 23:24:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9B3M0b29506;
	Tue, 10 Oct 2000 23:22:00 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9B3Lwb00867
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 23:21:58 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 329E72100; Tue, 10 Oct 2000 22:21:43 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id CEB8B217B
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 22:21:42 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000759163; Tue, 10 Oct 2000 23:21:02 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010110321.XAA0000759163@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Conference Call Agenda) 
In-reply-to: Your message of "Tue, 10 Oct 2000 17:08:46 EDT."
             <4.3.1.2.20001010165603.00b0db50@funnel.cisco.com> 
Date: Tue, 10 Oct 2000 23:20:56 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

can someone from dhcpv4 folks compare/contrast dhcpv4 reconfigure with
reconfigure-init?

Also is dhcpv4 using ERE as dhcpv6 reconfigure-init?

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Tue Oct 10 23:33:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19712;
	Tue, 10 Oct 2000 23:33:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9B3XNb29756;
	Tue, 10 Oct 2000 23:33:23 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9B3XAb12349
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 23:33:10 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 73C8823BF; Tue, 10 Oct 2000 22:32:54 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 19548230B
	for <dhcp-v6@bucknell.edu>; Tue, 10 Oct 2000 22:32:54 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000761058; Tue, 10 Oct 2000 23:32:52 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010110332.XAA0000761058@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-reply-to: Your message of "Tue, 10 Oct 2000 21:53:12 EDT."
             <200010110153.VAA01737@hygro.adsl.duke.edu> 
Date: Tue, 10 Oct 2000 23:32:51 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Thomas,

I think implementors need to pick good binding-ids.  Is as best we will
get.

In the current spec prefix+link-local will work but it has the NIC card
problem.  

I saw this when we restarted this discussion.  What we will do is make
the trade-off.

I am still not convinced that folks change their NIC cards enough to
loose the guranteed uniqueness we have in the current spec.
And it will come back to haunt us the first time servers crash because
of collisions.

Important trade-off decision we have to make.

/jim



From owner-dhcp-v6@bucknell.edu  Wed Oct 11 13:24:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15718;
	Wed, 11 Oct 2000 13:24:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BHLsb15322;
	Wed, 11 Oct 2000 13:21:54 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9BHLnb12501
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 13:21:49 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA00638 for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 13:21:33 -0400 (EDT)
Message-Id: <4.3.1.2.20001011132047.00b30de0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 11 Oct 2000 13:23:46 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200010060215.WAA0000835849@anw.zk3.dec.com>
References: <Your message of "Wed, 04 Oct 2000 22:32:36 PDT." <200010050532.e955Wa715415@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Issue: DHCPv6 address model.  Here's my summary of the discussion:

DHCP clients and servers will use Identity Associations (IAs) to
manage IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in
protocol messages.

Each IPv6 address has an associated preferred and valid lifetime.  The
lifetimes are determined by the server and handed to the client.
There are no restrictions on the scopes or number of IPv6 addresses in
an IA; an IA might contain just one IPv6 address or it might contain a
collection of global-, site- and link-local addresses.

The renewal time defines the time at which the client must contact the
server to get the current state of the IA (call this "renewing" the
IA).  The renewal time is independent of the address lifetimes of any
of the lifetimes of the IPv6 addresses in the IA.  It makes most sense
for the renewal time to be less than the preferred lifetimes of all of the
IPv6 addresses in the IA, and the renewal time must be less than the
valid lifetimes or the client will lose the use of some expired
addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  In any event, the server is
authoritative about the set of addresses and lifetimes in the IA.

The client must send all of the addresses associated with an IA when
renewing the IA.  The server examines this list of addresses and may
extend the lifetime or set the lifetime to zero of any addresses in
the IA.  The server may also add new addresses to the IA.  The server
returns the new IA to the client.

In all other transactions, the client sends the IA identifier and the
server returns IA identifier along with the list of addresses in the
IA.  The server is authoritative and the client simply records the IA
and configures the associated addresses.

TBD: During the address model discussion, we noted that the current
spec leaves the details of the renewal process to the DHCPv6 client
implementor.  I heard consensus that we should define the renewal
process and include it in the spec.



From owner-dhcp-v6@bucknell.edu  Wed Oct 11 13:59:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16513;
	Wed, 11 Oct 2000 13:59:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BHvIb14464;
	Wed, 11 Oct 2000 13:57:18 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9BHvCb14588
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 13:57:12 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2KVR>; Wed, 11 Oct 2000 13:56:57 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607072@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 11 Oct 2000 13:56:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph:

1) It might be useful to explicitly state the behavior of the server not
returning one or more addresses on a renewal (the implication is that the
client continue to use the missing address(es) until the lifetimes
previously communicated expire).

2) Ted was arguing NOT to include the list of addresses in client renewals
(but to include them in REBINDINGS, which need to be explicitly addressed in
the DHCPv6 specification). I personally would like to see them included
always, but we've debated that issue before.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Wednesday, October 11, 2000 1:24 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


Issue: DHCPv6 address model.  Here's my summary of the discussion:

DHCP clients and servers will use Identity Associations (IAs) to
manage IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in
protocol messages.

Each IPv6 address has an associated preferred and valid lifetime.  The
lifetimes are determined by the server and handed to the client.
There are no restrictions on the scopes or number of IPv6 addresses in
an IA; an IA might contain just one IPv6 address or it might contain a
collection of global-, site- and link-local addresses.

The renewal time defines the time at which the client must contact the
server to get the current state of the IA (call this "renewing" the
IA).  The renewal time is independent of the address lifetimes of any
of the lifetimes of the IPv6 addresses in the IA.  It makes most sense
for the renewal time to be less than the preferred lifetimes of all of the
IPv6 addresses in the IA, and the renewal time must be less than the
valid lifetimes or the client will lose the use of some expired
addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  In any event, the server is
authoritative about the set of addresses and lifetimes in the IA.

The client must send all of the addresses associated with an IA when
renewing the IA.  The server examines this list of addresses and may
extend the lifetime or set the lifetime to zero of any addresses in
the IA.  The server may also add new addresses to the IA.  The server
returns the new IA to the client.

In all other transactions, the client sends the IA identifier and the
server returns IA identifier along with the list of addresses in the
IA.  The server is authoritative and the client simply records the IA
and configures the associated addresses.

TBD: During the address model discussion, we noted that the current
spec leaves the details of the renewal process to the DHCPv6 client
implementor.  I heard consensus that we should define the renewal
process and include it in the spec.



From owner-dhcp-v6@bucknell.edu  Wed Oct 11 14:16:33 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16918;
	Wed, 11 Oct 2000 14:16:22 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BIFbb01630;
	Wed, 11 Oct 2000 14:15:37 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9BIFNb23018
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 14:15:23 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA07866; Wed, 11 Oct 2000 14:15:12 -0400 (EDT)
Message-Id: <4.3.1.2.20001011141140.00b1b390@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 11 Oct 2000 14:17:24 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607072@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 01:56 PM 10/11/00 -0400, Bernie Volz wrote:
>1) It might be useful to explicitly state the behavior of the server not
>returning one or more addresses on a renewal (the implication is that the
>client continue to use the missing address(es) until the lifetimes
>previously communicated expire).

Good point; I'll make that change.

>2) Ted was arguing NOT to include the list of addresses in client renewals
>(but to include them in REBINDINGS, which need to be explicitly addressed in
>the DHCPv6 specification). I personally would like to see them included
>always, but we've debated that issue before.

Well, this issue is a little tough to resolve with precision until we 
settle on a mechanism for IA extension.  The current spec doesn't 
differentiate between the DHCPv4 RENEW and REBIND actions.
Within the current spec, I could clarify by specifying that the addresses 
in an IA must be included in any multicast renewal message (I think that 
captures the circumstance in which the addresses must be communicated to a 
different server) - which would anticipate that we define a unicast RENEW 
and a multicast REBIND.

- Ralph




From owner-dhcp-v6@bucknell.edu  Wed Oct 11 14:19:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16954;
	Wed, 11 Oct 2000 14:19:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BIIDb00470;
	Wed, 11 Oct 2000 14:18:13 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9BII3b06230
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 14:18:04 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 460EF354C; Wed, 11 Oct 2000 14:17:48 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id EB2003580
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 14:17:47 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id OAA0000862696; Wed, 11 Oct 2000 14:17:42 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010111817.OAA0000862696@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 11 Oct 2000 13:23:46 EDT."
             <4.3.1.2.20001011132047.00b30de0@mail.bucknell.edu> 
Date: Wed, 11 Oct 2000 14:17:42 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Ralph,

>Each IPv6 address has an associated preferred and valid lifetime.  The
>lifetimes are determined by the server and handed to the client.
>There are no restrictions on the scopes or number of IPv6 addresses in
>an IA; an IA might contain just one IPv6 address or it might contain a
>collection of global-, site- and link-local addresses.

The server cannot give out link-local addresses they are determined at
boot time by an IPv6 node.  The reason is that link-local addresses are
automatically generated by IPv6 nodes and verified with Duplicate
Address Detection on the link.  

Also nodes using site-local addresses to connect to a dhcpv6 server
would mean the dhcpv6 server also has a similar site local address.
Clients should only use a site-local address when communicating with the
server if the server is in the same site as the client.  Multi-sited
dhcp servers should be acceed with greater scope than site-local which
today is only global.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Wed Oct 11 14:32:50 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17458;
	Wed, 11 Oct 2000 14:32:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BITYb23627;
	Wed, 11 Oct 2000 14:29:34 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BITTb02056
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 14:29:30 -0400 (EDT)
Received: (qmail 5351 invoked from network); 11 Oct 2000 18:29:28 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 11 Oct 2000 18:29:28 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier 
Date: Wed, 11 Oct 2000 11:29:34 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNOEGDCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200010110153.VAA01737@hygro.adsl.duke.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: Thomas Narten
> Sent: Tuesday, October 10, 2000 6:53 PM
>
[Barr]
> > One of the problems with the v4 spec is that the suggested method
> > for generating client identifiers leads to implementation issues
> > when the NIC is changed, and I'd like to avoid that again.
>
[Thomas]
> There is also a different issue, one that concerns me somewhat,
> though I'm not quite sure how much. If the client identifier is
> generated from the MAC on an interface, and that gets saved in
> stable storage (and reused from that point on per rule 1), there
> is an chance of collisions occuring when the interface get moved
> to a different machine, which subsequently generates a client
> indentifer using the same algorithm. ONe is relying on the "add a
> random component" part of the algorithm to generate good randomness.
> Maybe we can do that, but I am somewhat concerned that this will not
> be robust enough in practice.
>
[Barr]
...to help qualify this, my experience shows that many "low-cost" NICs have
reliability problems, yet many organizations prefer using them because the
cost of dispatching a skilled technician to diagnose network problems,
possibly replacing a faulty NIC after an hour or so of debugging, is MUCH
greater than simply replacing one NIC with another and throwing the old NIC
away!  Thus, in many instances, NICs are changed frequently.  If a certain
NIC fails 0.2% of the time, then   for a population of 100,000 NICs, one can
expect a NIC to fail every 3-4 days, which matches my experience pretty
well.

...this affects mostly legacy clients, as the reliability of NICs has been
steadily increasing, still, NIC failures do occur.

...because of the cost of diagnosing and repairing, or even returning failed
units to the manufacturer for refurbishing, having one NIC float from one
machine to another isn't very common, but what is quite common is for a
manufacturer to create identical configurations for a batch of, say, 3,000
machines, all based on an image with a particular NIC that was in the
manufacturer's lab.  There are a couple of scenarios where introducing such
machines into an environment will have the appearance of a "wandering NIC,"
as Thomas mentions.


[Thomas]
> We really want the vast majority of client IDs to be generated by the
> device maker at manufacture time (i.e, vendor ID plus serial
> number). Is this something that we are confident can be done today on
> effectively all devices?
>
[Barr]
> > I doubt it is possible to guarantee that UUIDs don't collide,
> > so a server implementation would be required to have some process
> > for dealing with collisions, regardless of how well-specified the
> > algorithm might be.
>
[Thomas]
> If there is a collision, what do you propose the server do? Seems to
> me that it has no way of distinguishing between the case where the
> same node is asking for different things (at different times) vs. two
> different nodes asking for information.
>
[Barr]
...in DHCPv4, there is an explicit and an implicit algorithm for resolving
conflicts, although it definitely could have been better specified:  FIRST,
use the Client Identifier as an index to an IP address lease;  THEN, if the
Client Identifier is not present, use the Client Hardware Address.  [before
anyone starts quoting the RFC to me, I'll admit I'm not quoting it exactly]

...implicitly, the third choice is if the IP address requested has been
assigned or is available for assignment, AND the server *somehow* determines
that the requesting client is entitled to use it.

...what DHCPv4 DOESN'T do is to explain how to resolve conflicts when BOTH a
Client Identifier and Hardware Address are present, but don't indicate the
same IP address lease.  If we were to ever revise the v4 RFC, I'd like this
to be clarified.

...I think it was unfortunate to suggest using the MAC address in the DHCPv4
RFC without regard to also suggesting or specifying how to resolve
conflicts.  Each of us probably has a slightly different take on this,
witness the long discussion last year on the ISC server mailing list about
how to do this in a completely reliable, unambiguous way.

...that brings us to DHCPv6:  do we specify a resolution process, or let
that be an implementor's decision?  I'm pretty happy with the general idea
of using a client-invariant serial number or other identifier, combined with
one or more other elements, randomized cryptographically, as the basis for
the client identifer.  But the question at the beginning of this paragraph
needs to be answered.

...comments?  suggestions?

--Barr Hibbs
  UltraDNS:  "We connect the dots in dot COM!"



From owner-dhcp-v6@bucknell.edu  Wed Oct 11 15:59:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20232;
	Wed, 11 Oct 2000 15:59:42 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BJufb18905;
	Wed, 11 Oct 2000 15:56:41 -0400 (EDT)
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9BJuTb27795
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 15:56:29 -0400 (EDT)
Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id MAA18037
	for <dhcp-v6@bucknell.edu>; Wed, 11 Oct 2000 12:56:13 -0700 (PDT)
Received: (from raj@localhost)
	by kitab.cisco.com (8.11.0/8.9.2) id e9BJuCK00985;
	Wed, 11 Oct 2000 12:56:12 -0700 (PDT)
	(envelope-from raj)
From: Richard Johnson <raj@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 11 Oct 2000 12:56:07 -0700 (PDT)
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010110153.VAA01737@hygro.adsl.duke.edu>
References: <rbhibbs@ultraDNS.com>
	<JCELKJCFMDGAKJCIGGPNGEFPCIAA.rbhibbs@ultraDNS.com>
	<200010110153.VAA01737@hygro.adsl.duke.edu>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14820.50522.514584.576067@kitab.cisco.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Thomas Narten writes:
 > We really want the vast majority of client IDs to be generated by the
 > device maker at manufacture time (i.e, vendor ID plus serial
 > number). Is this something that we are confident can be done today on
 > effectively all devices?

As far as I understand, the answer is a definite "no".  Projects I
have worked on here at cisco from time to have a searched for a unique 
serial number, etc., which could be used in this way and I've always
been informed there isn't one.  If someone else on this list knows
better, I'm interested.

/raj



From owner-dhcp-v6@bucknell.edu  Thu Oct 12 08:17:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22798;
	Thu, 12 Oct 2000 08:17:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CCFEb20020;
	Thu, 12 Oct 2000 08:15:14 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CCFDb13476
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 08:15:13 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (rtp-dial-1-218.cisco.com [10.83.97.218]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA18993 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 08:14:55 -0400 (EDT)
Message-Id: <4.3.1.2.20001012074734.00b1f260@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 12 Oct 2000 08:17:08 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607072@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I just finished writing this note, and see that it is *way* longer than one 
page.  So here's an executive summary:

The requirements of the failover protocol and explicit expiration of 
addresses in server-client messages combine to require that the client send 
its version of the IA - identifier and addresses - with every message to 
the server...

- Ralph

At 01:56 PM 10/11/00 -0400, you wrote:

>2) Ted was arguing NOT to include the list of addresses in client renewals
>(but to include them in REBINDINGS, which need to be explicitly addressed in
>the DHCPv6 specification). I personally would like to see them included
>always, but we've debated that issue before.

I think there is need for some additional clarity in this debate.  I see 
two issues influencing the inclusion of addresses with IAs in 
client->server communication:

1) The address expiration model: does the server expire addresses 
(effectively make the valid lifetime 0) by explicitly setting the address 
lifetime to 0 or implicitly by omitting the address from the IA?

2) Failover protocol: a client using multicast to extend the assignment 
time of an IA must include the addresses with the IA in case the extension 
request is received by the backup server, which has not received the 
information about the IA from the primary server.  In the case where the 
backup server does not know about the IA, it assumes the IA from the client 
is valid, extracts the information about the IA from the client message and 
commits the IA to its binding database.  Note: I used the terms 
"mutlticast", "extend", "extension" and "assignment time" here to describe 
the situation in the abstract without conflicting with terms like "renew", 
"RENEWING", "REBINDING" and "lease" from DHCPv4.

I'll work backwards: (2) requires that the addresses be included in any 
messages that might be received by the backup in a primary-backup failover 
pair before the backup has received the IA binding from the server.  This 
is the case when the client uses multicast to extend the assignment time of 
an IA, corresponding to a DHCPREQUEST message from a client in REBINDING 
state in DHCPv4.  I've heard WG consensus to require that IA addresses be 
included in these messages from the client.

(1) comes into play in any message in which the client thinks it knows the 
addresses in the IA; the corresponding states in DHCPv4 would be 
INIT-REBOOT and RENEWING.  In both of those cases, the server must know the 
addresses in the IA before it can expire any addresses that are no longer 
usable by the client.  In theory, because the server is authoritative, the 
server knows what addresses are in the IA and need not get the current 
state of the IA from the client.  In practice, if the client and server are 
out of sync, the server may not know all of the addresses in use by the 
client and therefore will not know to expire those addresses.  I think the 
requirement for explicit expiration and recognizing that clients and 
servers may be out of sync requires, as a belt-and-suspenders measure, that 
the client send the addresses with the IA any time it has addresses it 
thinks it can use.

So, it appears to me that the client should always send the entire IA to 
the server.  If the client thinks the IA is "empty" (i.e., a new IA for 
which the client is requesting address assignment), the client sends no 
addresses with the IA; otherwise, the client sends what it thinks is the 
current list of addresses in the IA.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Oct 12 10:51:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27864;
	Thu, 12 Oct 2000 10:51:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CEmbb06008;
	Thu, 12 Oct 2000 10:48:37 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CEmUb17401
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 10:48:30 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2LQF>; Thu, 12 Oct 2000 10:48:15 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE860360707A@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Thu, 12 Oct 2000 10:48:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph:

No complaint from me. While originally I had thought that saving the bytes
in the packet would be nice, I quickly changed my mind (it was Ted in fact
that triggered this change), but then discussions started about not sending
the addresses. I feel it best to send the addresses so I'm glad we've
(hopefully) settled on that.

>1) The address expiration model: does the server expire addresses 
>(effectively make the valid lifetime 0) by explicitly setting the address 
>lifetime to 0 or implicitly by omitting the address from the IA?

I assume that both techniques are valid. Omitting the address from the IA
means that whatever lifetimes that client previously had apply and it is
free to use the address until the lifetimes end. Explicitly setting the
address lifetime to 0 means that the server requests the client stop using
that address immediately.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Thursday, October 12, 2000 8:17 AM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 address model proposal...


I just finished writing this note, and see that it is *way* longer than one 
page.  So here's an executive summary:

The requirements of the failover protocol and explicit expiration of 
addresses in server-client messages combine to require that the client send 
its version of the IA - identifier and addresses - with every message to 
the server...

- Ralph

At 01:56 PM 10/11/00 -0400, you wrote:

>2) Ted was arguing NOT to include the list of addresses in client renewals
>(but to include them in REBINDINGS, which need to be explicitly addressed
in
>the DHCPv6 specification). I personally would like to see them included
>always, but we've debated that issue before.

I think there is need for some additional clarity in this debate.  I see 
two issues influencing the inclusion of addresses with IAs in 
client->server communication:

1) The address expiration model: does the server expire addresses 
(effectively make the valid lifetime 0) by explicitly setting the address 
lifetime to 0 or implicitly by omitting the address from the IA?

2) Failover protocol: a client using multicast to extend the assignment 
time of an IA must include the addresses with the IA in case the extension 
request is received by the backup server, which has not received the 
information about the IA from the primary server.  In the case where the 
backup server does not know about the IA, it assumes the IA from the client 
is valid, extracts the information about the IA from the client message and 
commits the IA to its binding database.  Note: I used the terms 
"mutlticast", "extend", "extension" and "assignment time" here to describe 
the situation in the abstract without conflicting with terms like "renew", 
"RENEWING", "REBINDING" and "lease" from DHCPv4.

I'll work backwards: (2) requires that the addresses be included in any 
messages that might be received by the backup in a primary-backup failover 
pair before the backup has received the IA binding from the server.  This 
is the case when the client uses multicast to extend the assignment time of 
an IA, corresponding to a DHCPREQUEST message from a client in REBINDING 
state in DHCPv4.  I've heard WG consensus to require that IA addresses be 
included in these messages from the client.

(1) comes into play in any message in which the client thinks it knows the 
addresses in the IA; the corresponding states in DHCPv4 would be 
INIT-REBOOT and RENEWING.  In both of those cases, the server must know the 
addresses in the IA before it can expire any addresses that are no longer 
usable by the client.  In theory, because the server is authoritative, the 
server knows what addresses are in the IA and need not get the current 
state of the IA from the client.  In practice, if the client and server are 
out of sync, the server may not know all of the addresses in use by the 
client and therefore will not know to expire those addresses.  I think the 
requirement for explicit expiration and recognizing that clients and 
servers may be out of sync requires, as a belt-and-suspenders measure, that 
the client send the addresses with the IA any time it has addresses it 
thinks it can use.

So, it appears to me that the client should always send the entire IA to 
the server.  If the client thinks the IA is "empty" (i.e., a new IA for 
which the client is requesting address assignment), the client sends no 
addresses with the IA; otherwise, the client sends what it thinks is the 
current list of addresses in the IA.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Oct 12 11:12:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29421;
	Thu, 12 Oct 2000 11:12:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CFBrb00723;
	Thu, 12 Oct 2000 11:11:53 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CFBeb31812
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 11:11:40 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA09654 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 11:11:24 -0400 (EDT)
Message-Id: <4.3.1.2.20001012105635.00aeb8d0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 12 Oct 2000 11:13:40 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
In-Reply-To: <63D30D6E10CFD11190A90000F805FE860360707A@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 10:48 AM 10/12/00 -0400, you wrote:

> >1) The address expiration model: does the server expire addresses
> >(effectively make the valid lifetime 0) by explicitly setting the address
> >lifetime to 0 or implicitly by omitting the address from the IA?
>
>I assume that both techniques are valid. Omitting the address from the IA
>means that whatever lifetimes that client previously had apply and it is
>free to use the address until the lifetimes end.

Right - however, I was trying to enumerate ways in which the server could 
terminate the client's use of an address immediately with extreme prejudice 
rather than allowing it to die a natural death.  So, I was describing the 
case in which the client would set the lifetime of any addresses not in the 
IA to 0.  My (1) should read:

1) The address expiration model: does the server expire addresses
(effectively make the valid lifetime 0) by explicitly setting the
address lifetime to 0 or implicitly by omitting the address
from the IA (in which case the client would set the lifetime
of any addresses not in the IA to 0).

>  Explicitly setting the
>address lifetime to 0 means that the server requests the client stop using
>that address immediately.

We agree here -

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Oct 12 13:44:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03115;
	Thu, 12 Oct 2000 13:44:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CHftb01541;
	Thu, 12 Oct 2000 13:41:55 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CHflb14019
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 13:41:48 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-129.ip.theriver.com [206.97.58.129]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9CHfNL22494 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 10:41:23 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e9CHd2s00953 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 10:39:03 -0700 (MST)
Message-Id: <200010121739.e9CHd2s00953@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Thu, 12 Oct 2000 10:48:13 -0400." <63D30D6E10CFD11190A90000F805FE860360707A@lespaul.process.com> 
Date: Thu, 12 Oct 2000 10:39:02 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> No complaint from me. While originally I had thought that saving the bytes
> in the packet would be nice, I quickly changed my mind (it was Ted in fact
> that triggered this change), but then discussions started about not sending
> the addresses. I feel it best to send the addresses so I'm glad we've
> (hopefully) settled on that.

I think we should say that the client SHOULD send its addresses, and
that if it doesn't it may not get clean failover behaviour.   That way
the cell phone people can decide what's more important to them -
completely robust failover or small packets.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Oct 12 14:19:22 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03489;
	Thu, 12 Oct 2000 14:19:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CIGGb13163;
	Thu, 12 Oct 2000 14:16:17 -0400 (EDT)
Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CIFqb03136
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 14:15:52 -0400 (EDT)
Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA00007
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 14:15:51 -0400 (EDT)
Date: Thu, 12 Oct 2000 14:15:51 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200010121739.e9CHd2s00953@grosse.bisbee.fugue.com>
Message-ID: <Pine.GSO.4.03.10010121413270.29999-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN



On Thu, 12 Oct 2000, Ted Lemon wrote:

> 
> > No complaint from me. While originally I had thought that saving the bytes
> > in the packet would be nice, I quickly changed my mind (it was Ted in fact
> > that triggered this change), but then discussions started about not sending
> > the addresses. I feel it best to send the addresses so I'm glad we've
> > (hopefully) settled on that.
> 
> I think we should say that the client SHOULD send its addresses, and
> that if it doesn't it may not get clean failover behaviour.   That way
> the cell phone people can decide what's more important to them -
> completely robust failover or small packets.

It's not just failover - in the case where the client thinks it knows some
addresses (e.g., the equivalent of DHCPv4 INIT-REBOOT), the server won't
be able to expire any of the client's addresses if it doesn't know the
client's current IA.  For example, if the client has plugged into a new
network segment, served by a different DHCP server than the one from which
the client originally obtained its IA, the server won't be able to expire
the old addresses unless the client sends them to the server.

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Oct 12 14:32:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03796;
	Thu, 12 Oct 2000 14:32:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CIW8b17824;
	Thu, 12 Oct 2000 14:32:08 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CIW2b24494
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 14:32:02 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-129.ip.theriver.com [206.97.58.129]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9CIVcL22656 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 11:31:38 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e9CITFs01706 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 11:29:15 -0700 (MST)
Message-Id: <200010121829.e9CITFs01706@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from "Ralph E. Droms" <droms@bucknell.edu> 
   of "Thu, 12 Oct 2000 14:15:51 -0400." <Pine.GSO.4.03.10010121413270.29999-100000@leo> 
Date: Thu, 12 Oct 2000 11:29:15 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Yes, well, that's why I wanted to specify that the client would throw
out any DHCP-acquired addresses not mentioned in a subsequent DHCP
Reply.  I still think that's the right thing to do - it adds a small
amount of hair to the client, which has to remember that it got some
addresses from DHCP and some from stateless, but I think it's actually
more efficient.   Besides, the client shouldn't be sending addresses
it got from stateless addrconf to the server, should it?   So it
*still* has to remember.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Oct 12 22:06:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12242;
	Thu, 12 Oct 2000 22:06:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9D22fb03175;
	Thu, 12 Oct 2000 22:02:41 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9D22Rb24255
	for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 22:02:27 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sj-dial-3-16.cisco.com [171.68.180.17]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA14894 for <dhcp-v6@bucknell.edu>; Thu, 12 Oct 2000 22:01:52 -0400 (EDT)
Message-Id: <4.3.1.2.20001012220101.00b34430@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 12 Oct 2000 22:01:24 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200010121829.e9CITFs01706@grosse.bisbee.fugue.com>
References: <Message from "Ralph E. Droms" <droms@bucknell.edu>
 <Pine.GSO.4.03.10010121413270.29999-100000@leo>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:29 AM 10/12/00 -0700, you wrote:

>Yes, well, that's why I wanted to specify that the client would throw
>out any DHCP-acquired addresses not mentioned in a subsequent DHCP
>Reply.  I still think that's the right thing to do - it adds a small
>amount of hair to the client, which has to remember that it got some
>addresses from DHCP and some from stateless, but I think it's actually
>more efficient.   Besides, the client shouldn't be sending addresses
>it got from stateless addrconf to the server, should it?   So it
>*still* has to remember.

Exactly.

- Ralph




From owner-dhcp-v6@bucknell.edu  Fri Oct 13 17:13:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11969;
	Fri, 13 Oct 2000 17:13:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DLAVb27183;
	Fri, 13 Oct 2000 17:10:31 -0400 (EDT)
Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9DLAJb02734
	for <dhcp-v6@bucknell.edu>; Fri, 13 Oct 2000 17:10:19 -0400 (EDT)
Received: from internaut.com (uucp@localhost)
	by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id OAA25577
	for bucknell.edu!dhcp-v6; Fri, 13 Oct 2000 14:10:19 -0700 (PDT)
Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0)
	id AA00180; Fri, 13 Oct 00 13:50:34 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Fri, 13 Oct 2000 14:08:44 -0700
Message-Id: <OJEJKOMOEAKLMOILFCPJAEECDHAA.aboba@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <JCELKJCFMDGAKJCIGGPNOEGDCIAA.rbhibbs@ultraDNS.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

[Thomas]
> If there is a collision, what do you propose the server do? Seems to
> me that it has no way of distinguishing between the case where the
> same node is asking for different things (at different times) vs. two
> different nodes asking for information.
>

The UUID space is large, but nevertheless there will be collisions. 
In terms of collision avoidance, there are a few things to think about:

a. How do nodes know when they've collided
b. How do they resolve the collision

In terms of collisions, I think that we only care about hosts with
identical UUIDs on the same LAN. So nodes learn about collisions by
listening to DHCPv6 traffic. Note that unlike neighbor discovery 
or mDNS, such traffic won't be frequent, so that a host choosing 
an already taken UUID isn't likely to have heard the previous 
traffic. So you have a situation with asymetric knowledge, 
where the original UUID owner may become aware of the 
collision, but the subsequent UUID claimers probably 
won't be aware of it. 

One possibility is for the origial UUID owner to "defend" the
claim, forcing the subsequent claimant to choose another UUID. 
I think that this may imply another message type, which probably
should be sent unicast. Note that in this model, there is an
implicit "first claimed first owned" model for resolving the
dispute. 

Another possibility is to have a tie breaker algorith, which
may cause the original owner to choose another UUID. My concern
is that this will cause the original owner to have to change 
addresses when the lease runs out. It is generally less disruptive 
to slightly delay a subsequent claimant in obtaining
an address on boot when they have no connections open as opposed
to forcing the original UUID owner with open connections to 
change their address thereby possibly losing some of them.



From owner-dhcp-v6@bucknell.edu  Fri Oct 13 17:39:59 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12301;
	Fri, 13 Oct 2000 17:39:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DLdGb15283;
	Fri, 13 Oct 2000 17:39:16 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9DLd2b19978
	for <dhcp-v6@bucknell.edu>; Fri, 13 Oct 2000 17:39:02 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2NV4>; Fri, 13 Oct 2000 17:38:46 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE86036070AC@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Fri, 13 Oct 2000 17:38:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

1) Defending only works if the defender is up and running. If it isn't, the
server might think this new client is the old client and assign it the
addresses. Once the original node returns, you might have a mess.

2) I don't think the statement that we need to keep the UUID unique to the
same LAN is true. If we're trying to make UUID unique to a client, that
client could easily be attached to several LANs and there is some potential
benefit if a server could know that when assigning addresses (assuming that
a single server is giving out the addresses for both LANs). This benefit
might also extend to management tools that query various servers (or their
repositories) to find out what addresses a single system has. I think the
UUID should ideally be unique to the DHCP server configuration (not
necessarily a single server, but many whether using failover, etc). Of
course, ideally it is universally unique.

3) The more we talk about this, the more I think this is too big a problem
to resolve in the short time we have to get the DHCPv6 draft out. Unless we
can find some prior art in this area - anyone located any?

4) Perhaps an interim solution is to define the UUID concept and today base
it on the hardware address of the interface. Perhaps the UUID today could be
defined as <UUID-type-code><hardware-type><hardware-address> where
UUID-type-code is something like 1 and hardware-type and hardware-address
are what we know them to be in DHCPv4. We might want to hash them in some
fashion. While sounding simple there are some more complex issues to  deal
with, such as what happens if a client no longer has this hardware-address.
Does it pick a new UUID or keep the old? My recommendation - pick a new UUID
(based on one of the hardware addresses). This dimishes the UUID value for
now, but avoids problems in case a new client were to get the original
hardware-address (since then you'd have two systems). Another issue is what
do systems that don't have very unqiue hardware addresses do?

Later, when systems get unique serial numbers or some such identifier, the
UUID can be derived from them instead (with a new UUID-type-code).


-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Friday, October 13, 2000 5:09 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier [collisions]


[Thomas]
> If there is a collision, what do you propose the server do? Seems to
> me that it has no way of distinguishing between the case where the
> same node is asking for different things (at different times) vs. two
> different nodes asking for information.
>

The UUID space is large, but nevertheless there will be collisions. 
In terms of collision avoidance, there are a few things to think about:

a. How do nodes know when they've collided
b. How do they resolve the collision

In terms of collisions, I think that we only care about hosts with
identical UUIDs on the same LAN. So nodes learn about collisions by
listening to DHCPv6 traffic. Note that unlike neighbor discovery 
or mDNS, such traffic won't be frequent, so that a host choosing 
an already taken UUID isn't likely to have heard the previous 
traffic. So you have a situation with asymetric knowledge, 
where the original UUID owner may become aware of the 
collision, but the subsequent UUID claimers probably 
won't be aware of it. 

One possibility is for the origial UUID owner to "defend" the
claim, forcing the subsequent claimant to choose another UUID. 
I think that this may imply another message type, which probably
should be sent unicast. Note that in this model, there is an
implicit "first claimed first owned" model for resolving the
dispute. 

Another possibility is to have a tie breaker algorith, which
may cause the original owner to choose another UUID. My concern
is that this will cause the original owner to have to change 
addresses when the lease runs out. It is generally less disruptive 
to slightly delay a subsequent claimant in obtaining
an address on boot when they have no connections open as opposed
to forcing the original UUID owner with open connections to 
change their address thereby possibly losing some of them.



From owner-dhcp-v6@bucknell.edu  Fri Oct 13 19:15:35 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13071;
	Fri, 13 Oct 2000 19:15:33 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DNCob01832;
	Fri, 13 Oct 2000 19:12:50 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DNCab14094
	for <dhcp-v6@bucknell.edu>; Fri, 13 Oct 2000 19:12:36 -0400 (EDT)
Received: (qmail 29291 invoked from network); 13 Oct 2000 23:12:35 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 13 Oct 2000 23:12:35 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Fri, 13 Oct 2000 16:12:45 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNAEHGCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <63D30D6E10CFD11190A90000F805FE86036070AC@lespaul.process.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> 1) Defending only works if the defender is up and running. If it
> isn't, the server might think this new client is the old client
> and assign it the addresses. Once the original node returns, you
> might have a mess.
>
...agreed: "defending" an assignment isn't something that a client should
do, and probably not even a server.  WHile a server might notice that its
leases are being "stolen" by a rogue or misconfigured server, or
misappropriated by a client, I think that human intervention will most often
be requred to resolve, so why include any sort of defense mechanism in the
protocol?


> 2) I don't think the statement that we need to keep the UUID
> unique to the same LAN is true. If we're trying to make UUID
> unique to a client, that client could easily be attached to
> several LANs and there is some potential benefit if a server
> could know that when assigning addresses (assuming that
> a single server is giving out the addresses for both LANs).
> This benefit might also extend to management tools that query
> various servers (or their repositories) to find out what addresses
> a single system has. I think the UUID should ideally be unique
> to the DHCP server configuration (not necessarily a single server,
> but many whether using failover, etc). Of course, ideally it is
> universally unique.
>
...while I think it is relatively difficult to define a universally unique
identifier, I believe we can define something that is relatively close, then
the collision detection mechanism (which I believe is a MUCH easier problem)
can be specified, if not algorithmically, at least by its characteristics


> 3) The more we talk about this, the more I think this is too big
> a problem to resolve in the short time we have to get the DHCPv6
> draft out.  Unless we can find some prior art in this area --
> anyone located any?
>
...I vote for the multi-component proposal, using cryptographically robust
methods to randomize it, as I've said before, then declaring the
characteristics of the collision detection and resolution process:  then we
can let implementors find the "best" way.


--Barr Hibbs,
  UltraDNS Corporation



From owner-dhcp-v6@bucknell.edu  Sat Oct 14 02:08:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00539;
	Sat, 14 Oct 2000 02:08:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9E65pb13854;
	Sat, 14 Oct 2000 02:05:51 -0400 (EDT)
Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9E65db14533
	for <dhcp-v6@bucknell.edu>; Sat, 14 Oct 2000 02:05:39 -0400 (EDT)
Received: from internaut.com (uucp@localhost)
	by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id XAA13668
	for bucknell.edu!dhcp-v6; Fri, 13 Oct 2000 23:05:38 -0700 (PDT)
Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0)
	id AA01913; Fri, 13 Oct 00 22:35:55 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Fri, 13 Oct 2000 22:54:05 -0700
Message-Id: <OJEJKOMOEAKLMOILFCPJIEFFDHAA.aboba@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <JCELKJCFMDGAKJCIGGPNAEHGCIAA.rbhibbs@ultraDNS.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

>...while I think it is relatively difficult to define a universally unique
>identifier, I believe we can define something that is relatively close,
then
>the collision detection mechanism (which I believe is a MUCH easier
problem)
>can be specified, if not algorithmically, at least by its characteristics

Ultimately, I think we only care about UUID collisions to the extent that
they result in address collisions, right? Assuming that we have a mechanism
to
detect address collisions, does this solve the problem?

> 3) The more we talk about this, the more I think this is too big
> a problem to resolve in the short time we have to get the DHCPv6
> draft out.  Unless we can find some prior art in this area --
> anyone located any?
>

I'm not sure I'm ready to give up yet.



From owner-dhcp-v6@bucknell.edu  Sat Oct 14 20:25:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06273;
	Sat, 14 Oct 2000 20:25:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9F0H2b20436;
	Sat, 14 Oct 2000 20:17:06 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9F0Gjb15485
	for <dhcp-v6@bucknell.edu>; Sat, 14 Oct 2000 20:16:53 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2N0A>; Sat, 14 Oct 2000 20:15:25 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE86036070B4@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Sat, 14 Oct 2000 20:15:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>Ultimately, I think we only care about UUID collisions to the extent that
>they result in address collisions, right? Assuming that we have a mechanism
>to detect address collisions, does this solve the problem?

I don't think so. Duplicate Address Detection at the link layer would likely
act to avoid two clients using the same addresses if they use the same UUID.
But weird events would happen (something like the following):
	Client A gets addresses
	Client B gets same addresses, DAD finds they are in use.
	Client B gets new addresses from server.
	Client A renews addesses.
	Client A gets same addresses, DAD finds they are in use.
	Client A gets new addresses from server.
	<Client A/B keep switching addresses ...>

If duplicate UUID's are rare and if we assume that lease times are
reasonable, perhaps the above isn't that bad? And, perhaps there is some
value in considering having a client generate a new UUID if the above
situation happens several times in a row?

>I'm not sure I'm ready to give up yet.

Good. I agree it would be useful to have a UUID.

- Bernie Volz

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Saturday, October 14, 2000 1:54 AM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier [collisions]


>...while I think it is relatively difficult to define a universally unique
>identifier, I believe we can define something that is relatively close,
then
>the collision detection mechanism (which I believe is a MUCH easier
problem)
>can be specified, if not algorithmically, at least by its characteristics

Ultimately, I think we only care about UUID collisions to the extent that
they result in address collisions, right? Assuming that we have a mechanism
to
detect address collisions, does this solve the problem?

> 3) The more we talk about this, the more I think this is too big
> a problem to resolve in the short time we have to get the DHCPv6
> draft out.  Unless we can find some prior art in this area --
> anyone located any?
>

I'm not sure I'm ready to give up yet.



From owner-dhcp-v6@bucknell.edu  Sun Oct 15 19:07:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11063;
	Sun, 15 Oct 2000 19:07:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9FN3wb03067;
	Sun, 15 Oct 2000 19:03:58 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9FN3lb31953
	for <dhcp-v6@bucknell.edu>; Sun, 15 Oct 2000 19:03:48 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 97AE63DEA; Sun, 15 Oct 2000 19:02:57 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 84DD93E31
	for <dhcp-v6@bucknell.edu>; Sun, 15 Oct 2000 19:02:57 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id TAA0000947301; Sun, 15 Oct 2000 19:02:51 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010152302.TAA0000947301@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier [collisions] 
In-reply-to: Your message of "Fri, 13 Oct 2000 14:08:44 PDT."
             <OJEJKOMOEAKLMOILFCPJAEECDHAA.aboba@internaut.com> 
Date: Sun, 15 Oct 2000 19:02:51 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I suggest if we head down the path to have dhcpv6 clients listen for
UUIDs on the LAN we add extensions to Neighbor Discovery.  Either way to
get this done and with consensus will not be quick.  Do we need to do
this for version 1 of dhcpv6?

Organizational User Identifier (OUI)
Why not state that another approach is to go get an OUI from XXX (I will
have to recall who) and we assume they are unique within an
organization.  Then we can work on future drafts or work to see if we
can and how we build a protocol to listen to each other to figure out UUID
or add extensions to Neighbor Discovery.

Worst case is the link-local + prefix will work for version 1.
And we have nothing to do?

/jim



From owner-dhcp-v6@bucknell.edu  Sun Oct 15 19:40:34 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11281;
	Sun, 15 Oct 2000 19:40:34 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9FNbvb26601;
	Sun, 15 Oct 2000 19:37:57 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9FNbmb05803
	for <dhcp-v6@bucknell.edu>; Sun, 15 Oct 2000 19:37:48 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (rtp-dial-2-120.cisco.com [10.83.96.120]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA28047 for <dhcp-v6@bucknell.edu>; Sun, 15 Oct 2000 19:37:26 -0400 (EDT)
Message-Id: <4.3.1.2.20001015122018.00b0da80@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 15 Oct 2000 15:11:38 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
In-Reply-To: <OJEJKOMOEAKLMOILFCPJAEECDHAA.aboba@internaut.com>
References: <JCELKJCFMDGAKJCIGGPNOEGDCIAA.rbhibbs@ultraDNS.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Executive summary:  There are two types of name collisions possible in the 
address model we've been discussing: collisions between IA identifiers and 
collisions between UUIDs.  The two types of collisions may have different 
outcomes.  Collisions between IA identifiers from hosts on different 
subnets may cause duplicate address assignment...

=====

At 02:08 PM 10/13/00 -0700, Bernard Aboba wrote:
>In terms of collisions, I think that we only care about hosts with
>identical UUIDs on the same LAN.

Bernard - your "only" in the sentence prompted me to do a little thinking 
about name collisions...

I think we need to clarify exactly what we mean by a collision - a 
collision between UUIDs will have one kind of impact on client-server 
operations while a collision between IA identifiers will have a different 
kind of impact.

I'm working here from our current working definition of an IA identifier as 
(UUID, binding-id), where UUID is a unique identifier for a host and a 
binding-id is an opaque cookie used to differentiate between IAs associated 
with one host.  In other words, IAs (123, 1), (123, 2) and (456, 1) all 
represent different IAs, and the first two IAs come from the same host.

So, suppose we have a network like this:


     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |         \      /
     +--------+          \----/
     UUID 123

where hosts A and B have both chosen to use the same UUID.  Now suppose 
hosts A and B ask for IAs (123, 1) and (123,2).  The DHCP server will 
assign some address from subnet X (IP.X) to (123,1) and some address from 
subnet Y (IP.Y) to (123,2).  The server will treat the two IAs as 
independent.  For the purposes of assigning other parameters, the server 
may treat the two IAs as being associated with a dual-homed host.  So, in 
this scenario I see that the DHCP server won't make any incorrect IP 
address assignments, but may make some errors in assigning other parameters 
because the server has reason to believe the two IAs are from the same host.

Now, suppose hosts A and B both contact the DHCP server for addresses for 
the same IA, (123, 1) and A goes first.  The DHCP server will assign IP.X 
to the IA and return that IA to A.  Later, when B contacts the DHCP server, 
the server will assign IP.Y to the IA and, presumably, release IP.X from 
the IA (more about this later!).  When A contacts the server to extend the 
assignment for (123,1), the server will assign an address from subnet X 
(perhaps IP.X again).  The net effect is that A and B each get an 
appropriate address, while the DHCP server bounces the IA back and forth 
between IP.X and IP.Y.  No specific problems, yet, but it sure doesn't feel 
right to have the IA out of sync with some of the address assignments.

Well, perhaps there is a potential problem.  In this diagram:

     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |      ---\      //
     +--------+     /    \----/
     UUID 123      /
                  /
     +--------+  /
     |        | /
     | Host C +/
     |        |
     +--------+
     UUID 456

suppose hosts A and B, sharing IA (123, 1) have been assigned IP.X and 
IP.y.  Now, host C contacts the DHCP server for an address for IA (456, 
1).  If the DHCP server has IP.X assigned to (123, 1), presumably IP.Y is 
free and may be assigned to host C.  Of course, host B is still using IP.Y, 
so there's a duplicate assignment of IP.Y to both B and C (more about this 
later, as well).

So, let's come back to the earlier scenario, where nodes A and B are 
sharing IA (123, 1).  We need to define the server behavior in the case 
where and IA moves from one subnet to another.  This is an area of some 
unclarity in DHCPv4.  If we make an assumption that all UUIDs or IA 
identifiers are unique, do we want to specify that a DHCP server MUST, 
SHOULD or MAY release any previously assigned addresses when an IA moves to 
a new subnet?  Perhaps there's another alternative - the server adds some 
more addresses to the IA (leaving the old [presumably now unusable] 
addresses in the IA)?

At the end of the second example of shared IAs, I noted the case in which 
IP.Y might be assigned to both nodes B and C.  Will the DHCP server 
(through ping or some other remote DAD mechanism) or the nodes themselves 
(doing DAD) notice the problem?  Given that the server or the nodes have 
noticed the problem, is there anything the server or the nodes or an 
administrator can do about it?

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 00:15:59 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14951;
	Mon, 16 Oct 2000 00:15:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9G4DIb08659;
	Mon, 16 Oct 2000 00:13:18 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9G4D2b29511
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 00:13:02 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id D62683C55; Mon, 16 Oct 2000 00:12:46 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id A6FDF3D00
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 00:12:46 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000971411; Mon, 16 Oct 2000 00:12:43 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010160412.AAA0000971411@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier [collisions] 
In-reply-to: Your message of "Sun, 15 Oct 2000 15:11:38 EDT."
             <4.3.1.2.20001015122018.00b0da80@mail.bucknell.edu> 
Date: Mon, 16 Oct 2000 00:12:43 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

prefix + link-local won't work now regardless of the nic issue. 
The reason is the security benefits from UUIDs.  So I forget that.

OUI - I just checked the IEEE page and that won't work cause you have to
buy it and order it and whatever and that is not good as we want nodes
to be able to have multiple IAs if they desire, and this will put just
to much administrative complexity on the end user site.

But we do need to nail down the UUID.  Maybe Barr's idea will work for
version 1? 

Then I thought in your diagram below:

     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |      ---\      //
     +--------+     /    \----/
     UUID 123      /
                  /
     +--------+  /
     |        | /
     | Host C +/
     |        |
     +--------+
     UUID 456

Host A and Host B and C are on different subnets.  In IPv6 you cannot
duplicate prefixes across links.  

So it would be valid to have subnet prefixes:

4ffe (A's subnet) Subnet X
3ffe (B's subnet) Subnet Y
3ffe (C's subnet) Subnet Y

It would not be valid to have:

4ffe (A's subnet)
3ffe (B's subnet) 
4ffe (C's subnet)

So IPv6 rules out 4ffe from being on subnet Y.

If we extend the IA model as follows:

  (Prefix, UUID, binding-id)

Host A IA would be:  (4ffe, 123, ?)
Host B IA would be:  (3ffe, 123, ?)
Host C IA would be:  (3ffe, 256, ?)

We can use DAD today (I need to check the code for sure) to take the
prefix+UUID and do DAD.  So we can prevent duplicate UUIDs on a Link
(subnet in IPv4 terms).  When prefixes change though thru router
advertisements the UUID would have to be reverified.  We would have to
write all this up in DHCPv6 to if we wanted to use DAD in IPv6.  Also if
their are not routers on the link and ONLY a DHCPv6 server we need to
know that (the IPv6 Dentist Office Scenario).  Other parts need to be
checked if we think this is a good idea.  This would I think answer
Bernard's question to discover if the UUID was duplicated on a link. The
IPv6 implementations already have this code running so not hard to
figure it out.  Now I will go back to your mail and see what happens:

>suppose hosts A and B, sharing IA (123, 1) have been assigned IP.X and 
>IP.y.  Now, host C contacts the DHCP server for an address for IA (456, 
>1).  If the DHCP server has IP.X assigned to (123, 1), presumably IP.Y is 
>free and may be assigned to host C.  Of course, host B is still using IP.Y, 
>so there's a duplicate assignment of IP.Y to both B and C (more about this 
>later, as well).

Now the server would differetiate A and B by the different prefixes when
C asks for an address because it would know:

Server Database:
4ffe 123 ? := IP.X
     aaa ? := IP.X+1  (other UUIDs on 4ffe)
     bbb ? := IP.X+2    "      "       "
3ffe 123 ? := IP.Y
     ccc ? := IP.Y+1  (other UUIDs on 3ffe)


In this case the server would not IP.Y has been given out and would give
Host C IP.Y+2.

>So, let's come back to the earlier scenario, where nodes A and B are 
>sharing IA (123, 1).  We need to define the server behavior in the case 
>where and IA moves from one subnet to another.  This is an area of some 
>unclarity in DHCPv4.  If we make an assumption that all UUIDs or IA 
>identifiers are unique, do we want to specify that a DHCP server MUST, 
>SHOULD or MAY release any previously assigned addresses when an IA moves to 
>a new subnet?  Perhaps there's another alternative - the server adds some 
>more addresses to the IA (leaving the old [presumably now unusable] 
>addresses in the IA)?

I think the answer is yes and it should be a SHOULD.  Not all clients
that move may be able to do the release, hence, not a MUST.  But if the
client did not release the addresses to the server it MUST stop using
them when it roams to another subnet, because the addresses may not be 
reachable at the next location.

But lets say the client C moves to subnet Z now which has prefix 5ffe.
The client builds a new IA but keeps its UUID for security:

5ffe 456 ? := IP.Z

The old:

3ffe 456 ? �? := IP.Y+2 would time out.

>At the end of the second example of shared IAs, I noted the case in which 
>IP.Y might be assigned to both nodes B and C.  Will the DHCP server 
>(through ping or some other remote DAD mechanism) or the nodes themselves 
>(doing DAD) notice the problem?  Given that the server or the nodes have 
>noticed the problem, is there anything the server or the nodes or an 
>administrator can do about it?

With the prefix in the IA B and C could never be assigned the same
address so it cannot happen.  Nor the same UUID on the link because of 
DAD in IPv6.

The scenario above would work with all existing IPv6 implementations
quickly for deployment and not much new code would have to be
reinvented.

The security advantage of the UUID would still be applicable even when
the node roams.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 00:38:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15163;
	Mon, 16 Oct 2000 00:38:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9G4bnb06485;
	Mon, 16 Oct 2000 00:37:49 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9G4bhb22340
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 00:37:43 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id CCF2A4609; Sun, 15 Oct 2000 23:37:27 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 0B2754414
	for <dhcp-v6@bucknell.edu>; Sun, 15 Oct 2000 23:37:27 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000973061; Mon, 16 Oct 2000 00:37:25 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010160437.AAA0000973061@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Conference Call Agenda) 
In-reply-to: Your message of "Tue, 10 Oct 2000 23:20:56 EDT."
             <200010110321.XAA0000759163@anw.zk3.dec.com> 
Date: Mon, 16 Oct 2000 00:37:24 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>From Jim Bound
>can someone from dhcpv4 folks compare/contrast dhcpv4 reconfigure with
>reconfigure-init?
>
>Also is dhcpv4 using ERE as dhcpv6 reconfigure-init?

I went and did this myself.

draft-ietf-dhc-pv4-reconfigure-01.txt

The FORCERENEW is on the surface like the DHCPRECONFIGURE-INIT except the
dhcpv6 one permits multicast which I think we should in some form.

But there is now ERE concept with DHCPRECONFIGURE-INIT too.

Also it appears to me the core design purpose is a bit different and
goals.  The FORCERENEW is basically to tell the client to come get a new
lease.  The DHCPCONFIGURE-INT also can provide a hint to the client via the
ERE come get ERE:X. Where X is an extension type.  

Also FORCERENEW forces the client into the RENEW state.  In DHCPv6 we
don't have states but in our case the DHCPRECONFIGURE-INIT may not be telling
the client to RENEW or to do a DHCPREQUEST with IA and Address
Extension.

It could be come get a new TCP_KEEPALIVE, or POSIX-TIMEZONE variable, or
DNS SERVER record.  Or as we are working in ngtrans right now come get a
new IPv4-Mapped address for the Dual Stack Transition Method (DSTM).
http://ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-02.txt
The actual format for the ERE and Extension is defined above.

I would like to hear from folks on the above as I think we are in
agreement we need DHCPRECONFIGURE-INIT but the issue is DHCPRECONFIGURE
and DHCPRECONFIGUREREPLY?   I feel the ERE mechanism for DHCPRECONFIGURE-INIT
is very important to IPv6 and I would like to hear why anyone thinks it
is not or if you agree with me.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 13:10:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10874;
	Mon, 16 Oct 2000 13:10:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GH6Xb22857;
	Mon, 16 Oct 2000 13:06:33 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GH6Lb04427
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 13:06:21 -0400 (EDT)
Received: (qmail 31305 invoked from network); 16 Oct 2000 17:06:19 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 16 Oct 2000 17:06:19 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Mon, 16 Oct 2000 10:06:52 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNEEHLCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <OJEJKOMOEAKLMOILFCPJIEFFDHAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Bernard Aboba
> Sent: Friday, October 13, 2000 10:54 PM

>
> >...while I think it is relatively difficult to define a
> universally unique
> >identifier, I believe we can define something that is relatively close,
> then
> >the collision detection mechanism (which I believe is a MUCH easier
> problem)
> >can be specified, if not algorithmically, at least by its characteristics
>
> Ultimately, I think we only care about UUID collisions to the extent that
> they result in address collisions, right? Assuming that we have a
> mechanism
> to
> detect address collisions, does this solve the problem?
>
...agreed: all we really care about is detection -- at least in an RFC --
though I maintain it would be very useful to define the characteristics of a
resolution mechanism, mostly to avoid misinterpretations which have plagued
DHCPv4


--Barr Hibbs



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 13:16:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11053;
	Mon, 16 Oct 2000 13:16:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GHGNb25594;
	Mon, 16 Oct 2000 13:16:23 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GHGLb16799
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 13:16:21 -0400 (EDT)
Received: (qmail 31636 invoked from network); 16 Oct 2000 17:16:20 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 16 Oct 2000 17:16:20 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions] 
Date: Mon, 16 Oct 2000 10:16:53 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNKEHLCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200010160412.AAA0000971411@anw.zk3.dec.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: Jim Bound
> Sent: Sunday, October 15, 2000 9:13 PM
>
>
> Ralph,
>
> prefix + link-local won't work now regardless of the nic issue.
> The reason is the security benefits from UUIDs.  So I forget that.
>
> OUI - I just checked the IEEE page and that won't work cause you have to
> buy it and order it and whatever and that is not good as we want nodes
> to be able to have multiple IAs if they desire, and this will put just
> to much administrative complexity on the end user site.
>
> But we do need to nail down the UUID.  Maybe Barr's idea will work for
> version 1?
>
>

...wow!  this is all very interesting, but seems to have strayed from my
original point, which was meant to cover the following case:

  +------------+     +-----+
  |   Host A   |     |     |
  | Client ID: +-----+  N  |
  |    1023    |     |  E  |     +========+
  +------------+     |  T  |     |  DHCP  |
                     |  W  +-----+ Server |
  +------------+     |  O  |     |        |
  |   Host B   |     |  R  |     +========+
  | Client ID: +-----+  K  |
  |    1023    |     |     |
  +------------+     +-----+

Thus my two questions:
(1) can we reliably detect that Client ID 1023 has been chosen by DIFFERENT
hosts?
(2) can we SUGGEST ways to resolve this collision that don't create other
problems?

(1) arises because I'm not convinced that it is possible to guarantee
uniqueness of any identifier, so, better to be prepared to deal with its
occurrence

(2) arises because of similar problems with the DHCPv4 client identifier

--Barr Hibbs



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 13:37:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11579;
	Mon, 16 Oct 2000 13:37:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GHaab22420;
	Mon, 16 Oct 2000 13:36:36 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GHaJb11579
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 13:36:19 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id CEED98D0F; Mon, 16 Oct 2000 13:35:56 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 9D4F28896
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 13:35:56 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id NAA0000580974; Mon, 16 Oct 2000 13:35:56 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010161735.NAA0000580974@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Discussion: client identifier [collisions] 
In-reply-to: Your message of "Mon, 16 Oct 2000 10:16:53 PDT."
             <JCELKJCFMDGAKJCIGGPNKEHLCIAA.rbhibbs@ultraDNS.com> 
Date: Mon, 16 Oct 2000 13:35:56 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN



>  +------------+     +-----+
>  |   Host A   |     |     |
>  | Client ID: +-----+  N  |
>  |    1023    |     |  E  |     +========+
>  +------------+     |  T  |     |  DHCP  |
>                     |  W  +-----+ Server |
>  +------------+     |  O  |     |        |
>  |   Host B   |     |  R  |     +========+
>  | Client ID: +-----+  K  |
>  |    1023    |     |     |
>  +------------+     +-----+
>
>Thus my two questions:
>(1) can we reliably detect that Client ID 1023 has been chosen by DIFFERENT
>hosts?

I sent mail last night can you respond to that where yes we can verify
this on a link using DAD but not across several links.  Links in IPv6
are subnets in IPv4 basically.

>(2) can we SUGGEST ways to resolve this collision that don't create other
>problems?

Yes in same mail above I suggest using the IPv6 Prefix which is unique
to each link in a site.  Can you respond to that mail.  I think it
solves the problem.

>(1) arises because I'm not convinced that it is possible to guarantee
>uniqueness of any identifier, so, better to be prepared to deal with its
>occurrence

Yes that is why the prefix must be part of the IA in DHCPv6.

>(2) arises because of similar problems with the DHCPv4 client identifier

Yes I can see that DHCPv4 has same problem.  The tightened up rule set
for IPv6 can help for DHCPv6 with the prefix allocations.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 13:56:16 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12000;
	Mon, 16 Oct 2000 13:56:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GHrCb31976;
	Mon, 16 Oct 2000 13:53:12 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GHrBb10106
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 13:53:11 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY236L>; Mon, 16 Oct 2000 13:52:55 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE86036070C5@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Mon, 16 Oct 2000 13:52:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

How about we consider a UUID timestamp or some such thing (either separately
or as a part of the UUID)?

Here's what happens ... when a client boots and no UUID exists, it first
(solicits and) awaits an ADVERTISE from a DHCP Server. In this ADVERTISE we
have a server time stamp or UUID generation key. When the client receives
this (unicast) ADVERTISE, it then generates a UUID consisting of (a)
hardware information of some type (either NIC or manufacturer/serial, etc),
(b) the timestamp, and (c) a random number. It then saves this UUID and uses
it 'forever' (it if has no stable storage, then it would generate a new UUID
at each boot).

Assuming the timestamp is at least 32-bits and the random number is also at
least 32-bits, and the hardware information is also 48-bits, we should have
an extremely small probility of a collison. The only issue is if there are
multiple servers and they happen to send out the same timestamp in
ADVERTISEs. But, if the ADVERTISE that is used is for the server that will
be contacted, then you're at least assured that for that server there will
never be two clients with the same UUID.

- Bernie Volz

-----Original Message-----
From: Barr Hibbs [mailto:rbhibbs@ultraDNS.com]
Sent: Monday, October 16, 2000 1:17 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier [collisions]



> -----Original Message-----
> From: Jim Bound
> Sent: Sunday, October 15, 2000 9:13 PM
>
>
> Ralph,
>
> prefix + link-local won't work now regardless of the nic issue.
> The reason is the security benefits from UUIDs.  So I forget that.
>
> OUI - I just checked the IEEE page and that won't work cause you have to
> buy it and order it and whatever and that is not good as we want nodes
> to be able to have multiple IAs if they desire, and this will put just
> to much administrative complexity on the end user site.
>
> But we do need to nail down the UUID.  Maybe Barr's idea will work for
> version 1?
>
>

...wow!  this is all very interesting, but seems to have strayed from my
original point, which was meant to cover the following case:

  +------------+     +-----+
  |   Host A   |     |     |
  | Client ID: +-----+  N  |
  |    1023    |     |  E  |     +========+
  +------------+     |  T  |     |  DHCP  |
                     |  W  +-----+ Server |
  +------------+     |  O  |     |        |
  |   Host B   |     |  R  |     +========+
  | Client ID: +-----+  K  |
  |    1023    |     |     |
  +------------+     +-----+

Thus my two questions:
(1) can we reliably detect that Client ID 1023 has been chosen by DIFFERENT
hosts?
(2) can we SUGGEST ways to resolve this collision that don't create other
problems?

(1) arises because I'm not convinced that it is possible to guarantee
uniqueness of any identifier, so, better to be prepared to deal with its
occurrence

(2) arises because of similar problems with the DHCPv4 client identifier

--Barr Hibbs



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 13:57:42 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12023;
	Mon, 16 Oct 2000 13:57:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GHvIb09012;
	Mon, 16 Oct 2000 13:57:18 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GHvAb12262
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 13:57:11 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY236T>; Mon, 16 Oct 2000 13:56:55 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE86036070C6@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Mon, 16 Oct 2000 13:56:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Oh ... we could also have the SOLICIT request a UUID from a server and have
the server return the UUID in the ADVERTISE. And, the UUID would have some
server identifier included in it - so that hopefully no two servers ever
have the same identifier. This could be something like the server's hardware
address or some unique identifier. At least that makes the problem more
manageable - keeping the server identifiers unique. The only other problem
of course is if a server looses its stable storage (since it no longer has a
record of the UUIDs given out or the 'next UUID number').

- Bernei Volz

-----Original Message-----
From: Bernie Volz 
Sent: Monday, October 16, 2000 1:53 PM
To: 'dhcp-v6@bucknell.edu'
Subject: RE: Discussion: client identifier [collisions]


How about we consider a UUID timestamp or some such thing (either separately
or as a part of the UUID)?

Here's what happens ... when a client boots and no UUID exists, it first
(solicits and) awaits an ADVERTISE from a DHCP Server. In this ADVERTISE we
have a server time stamp or UUID generation key. When the client receives
this (unicast) ADVERTISE, it then generates a UUID consisting of (a)
hardware information of some type (either NIC or manufacturer/serial, etc),
(b) the timestamp, and (c) a random number. It then saves this UUID and uses
it 'forever' (it if has no stable storage, then it would generate a new UUID
at each boot).

Assuming the timestamp is at least 32-bits and the random number is also at
least 32-bits, and the hardware information is also 48-bits, we should have
an extremely small probility of a collison. The only issue is if there are
multiple servers and they happen to send out the same timestamp in
ADVERTISEs. But, if the ADVERTISE that is used is for the server that will
be contacted, then you're at least assured that for that server there will
never be two clients with the same UUID.

- Bernie Volz

-----Original Message-----
From: Barr Hibbs [mailto:rbhibbs@ultraDNS.com]
Sent: Monday, October 16, 2000 1:17 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier [collisions]



> -----Original Message-----
> From: Jim Bound
> Sent: Sunday, October 15, 2000 9:13 PM
>
>
> Ralph,
>
> prefix + link-local won't work now regardless of the nic issue.
> The reason is the security benefits from UUIDs.  So I forget that.
>
> OUI - I just checked the IEEE page and that won't work cause you have to
> buy it and order it and whatever and that is not good as we want nodes
> to be able to have multiple IAs if they desire, and this will put just
> to much administrative complexity on the end user site.
>
> But we do need to nail down the UUID.  Maybe Barr's idea will work for
> version 1?
>
>

...wow!  this is all very interesting, but seems to have strayed from my
original point, which was meant to cover the following case:

  +------------+     +-----+
  |   Host A   |     |     |
  | Client ID: +-----+  N  |
  |    1023    |     |  E  |     +========+
  +------------+     |  T  |     |  DHCP  |
                     |  W  +-----+ Server |
  +------------+     |  O  |     |        |
  |   Host B   |     |  R  |     +========+
  | Client ID: +-----+  K  |
  |    1023    |     |     |
  +------------+     +-----+

Thus my two questions:
(1) can we reliably detect that Client ID 1023 has been chosen by DIFFERENT
hosts?
(2) can we SUGGEST ways to resolve this collision that don't create other
problems?

(1) arises because I'm not convinced that it is possible to guarantee
uniqueness of any identifier, so, better to be prepared to deal with its
occurrence

(2) arises because of similar problems with the DHCPv4 client identifier

--Barr Hibbs



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 15:22:31 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13993;
	Mon, 16 Oct 2000 15:22:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GJHJb05111;
	Mon, 16 Oct 2000 15:17:19 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GJH6b16461
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 15:17:06 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2309>; Mon, 16 Oct 2000 15:16:50 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE86036070D0@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
Date: Mon, 16 Oct 2000 15:16:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>So, let's come back to the earlier scenario, where nodes A and B are 
>sharing IA (123, 1).  We need to define the server behavior in the case 
>where and IA moves from one subnet to another.  This is an area of some 
>unclarity in DHCPv4.  If we make an assumption that all UUIDs or IA 
>identifiers are unique, do we want to specify that a DHCP server MUST, 
>SHOULD or MAY release any previously assigned addresses when an IA moves to

>a new subnet?  Perhaps there's another alternative - the server adds some 
>more addresses to the IA (leaving the old [presumably now unusable] 
>addresses in the IA)?

I personally have never been confortable with removing the addresses on
other subnets. For multi-homed hosts, how do you know that those addresses
aren't in use? I would recommend that the server keep the addresses on file
until the lifetimes expire. You could easily have:

     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +---+----+          \----/          \-+             |
         |                                 | DHCP server |
         |               /----\          /-+             |
         |              /      \    /---/  +-------------+
         +------------+ Subnet Y +-/
                        \      /
                         \----/

Perhaps we'd assume that in this case the two IAs would be different, but
I'm not sure why that has to be a requirement.

- Bernie Volz


-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Sunday, October 15, 2000 3:12 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier [collisions]


Executive summary:  There are two types of name collisions possible in the 
address model we've been discussing: collisions between IA identifiers and 
collisions between UUIDs.  The two types of collisions may have different 
outcomes.  Collisions between IA identifiers from hosts on different 
subnets may cause duplicate address assignment...

=====

At 02:08 PM 10/13/00 -0700, Bernard Aboba wrote:
>In terms of collisions, I think that we only care about hosts with
>identical UUIDs on the same LAN.

Bernard - your "only" in the sentence prompted me to do a little thinking 
about name collisions...

I think we need to clarify exactly what we mean by a collision - a 
collision between UUIDs will have one kind of impact on client-server 
operations while a collision between IA identifiers will have a different 
kind of impact.

I'm working here from our current working definition of an IA identifier as 
(UUID, binding-id), where UUID is a unique identifier for a host and a 
binding-id is an opaque cookie used to differentiate between IAs associated 
with one host.  In other words, IAs (123, 1), (123, 2) and (456, 1) all 
represent different IAs, and the first two IAs come from the same host.

So, suppose we have a network like this:


     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |         \      /
     +--------+          \----/
     UUID 123

where hosts A and B have both chosen to use the same UUID.  Now suppose 
hosts A and B ask for IAs (123, 1) and (123,2).  The DHCP server will 
assign some address from subnet X (IP.X) to (123,1) and some address from 
subnet Y (IP.Y) to (123,2).  The server will treat the two IAs as 
independent.  For the purposes of assigning other parameters, the server 
may treat the two IAs as being associated with a dual-homed host.  So, in 
this scenario I see that the DHCP server won't make any incorrect IP 
address assignments, but may make some errors in assigning other parameters 
because the server has reason to believe the two IAs are from the same host.

Now, suppose hosts A and B both contact the DHCP server for addresses for 
the same IA, (123, 1) and A goes first.  The DHCP server will assign IP.X 
to the IA and return that IA to A.  Later, when B contacts the DHCP server, 
the server will assign IP.Y to the IA and, presumably, release IP.X from 
the IA (more about this later!).  When A contacts the server to extend the 
assignment for (123,1), the server will assign an address from subnet X 
(perhaps IP.X again).  The net effect is that A and B each get an 
appropriate address, while the DHCP server bounces the IA back and forth 
between IP.X and IP.Y.  No specific problems, yet, but it sure doesn't feel 
right to have the IA out of sync with some of the address assignments.

Well, perhaps there is a potential problem.  In this diagram:

     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |      ---\      //
     +--------+     /    \----/
     UUID 123      /
                  /
     +--------+  /
     |        | /
     | Host C +/
     |        |
     +--------+
     UUID 456

suppose hosts A and B, sharing IA (123, 1) have been assigned IP.X and 
IP.y.  Now, host C contacts the DHCP server for an address for IA (456, 
1).  If the DHCP server has IP.X assigned to (123, 1), presumably IP.Y is 
free and may be assigned to host C.  Of course, host B is still using IP.Y, 
so there's a duplicate assignment of IP.Y to both B and C (more about this 
later, as well).

So, let's come back to the earlier scenario, where nodes A and B are 
sharing IA (123, 1).  We need to define the server behavior in the case 
where and IA moves from one subnet to another.  This is an area of some 
unclarity in DHCPv4.  If we make an assumption that all UUIDs or IA 
identifiers are unique, do we want to specify that a DHCP server MUST, 
SHOULD or MAY release any previously assigned addresses when an IA moves to 
a new subnet?  Perhaps there's another alternative - the server adds some 
more addresses to the IA (leaving the old [presumably now unusable] 
addresses in the IA)?

At the end of the second example of shared IAs, I noted the case in which 
IP.Y might be assigned to both nodes B and C.  Will the DHCP server 
(through ping or some other remote DAD mechanism) or the nodes themselves 
(doing DAD) notice the problem?  Given that the server or the nodes have 
noticed the problem, is there anything the server or the nodes or an 
administrator can do about it?

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct 16 15:42:57 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14554;
	Mon, 16 Oct 2000 15:42:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GJfsb18016;
	Mon, 16 Oct 2000 15:41:54 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GJfgb12784
	for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 15:41:43 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA23480 for <dhcp-v6@bucknell.edu>; Mon, 16 Oct 2000 15:41:18 -0400 (EDT)
Message-Id: <4.3.1.2.20001016153946.00b5e100@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 16 Oct 2000 15:43:29 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: Discussion: client identifier [collisions]
In-Reply-To: <63D30D6E10CFD11190A90000F805FE86036070D0@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 03:16 PM 10/16/00 -0400, Bernie Volz wrote:
> >If we make an assumption that all UUIDs or IA
> >identifiers are unique, do we want to specify that a DHCP server MUST,
> >SHOULD or MAY release any previously assigned addresses when an IA moves to
> >a new subnet?
>
>I personally have never been confortable with removing the addresses on
>other subnets. For multi-homed hosts, how do you know that those addresses
>aren't in use? I would recommend that the server keep the addresses on file
>until the lifetimes expire. You could easily have:
>
>      UUID 123
>      +--------+          /----\
>      |        |         /      \
>      | Host A +-------+ Subnet X +-\
>      |        |         \      /    \---\  +-------------+
>      +---+----+          \----/          \-+             |
>          |                                 | DHCP server |
>          |               /----\          /-+             |
>          |              /      \    /---/  +-------------+
>          +------------+ Subnet Y +-/
>                         \      /
>                          \----/
>
>Perhaps we'd assume that in this case the two IAs would be different, but
>I'm not sure why that has to be a requirement.

I think this is exactly the situation Ted talked about in one of the first 
messages in this thread (9/6):

>Having one identity association per network
>interface avoids this problem - if you are multiply attached, you'll
>have multiple identity associations, and if you're singly attached, I
>can nuke your old lease when you change networks.

I agree with Ted...

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Oct 19 13:19:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02035;
	Thu, 19 Oct 2000 13:19:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JHH5b20661;
	Thu, 19 Oct 2000 13:17:05 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JHGmb09369
	for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 13:16:49 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA01300 for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 13:16:30 -0400 (EDT)
Message-Id: <4.3.1.2.20001019131342.00b91ab0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 19 Oct 2000 13:16:23 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <4.3.1.2.20001012220101.00b34430@mail.bucknell.edu>
References: <200010121829.e9CITFs01706@grosse.bisbee.fugue.com>
 <Message from "Ralph E. Droms" <droms@bucknell.edu>
 <Pine.GSO.4.03.10010121413270.29999-100000@leo>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Here's my latest summary of the DHCPv6 address model.  I've included a 
summary of changes from the previous model and  a list of 3 TBD issues at 
the end of the summary.

Please review this summary and post any comments.  If we have any 
unresolved issues I'll add them to the draft for discussion at our next 
design team phone call.

- Ralph

=====

Issue: DHCPv6 address model.  Here's my summary of the discussion:

DHCP clients and servers will use Identity Associations (IAs) to
manage IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in
protocol messages.

Each IPv6 address has an associated preferred and valid lifetime.  The
lifetimes are determined by the server and handed to the client.
There are no restrictions on the scopes or number of IPv6 addresses in
an IA; an IA might contain just one IPv6 address or it might contain a
collection of global- and  site-local addresses.

The renewal time defines the time at which the client must contact the
server to get the current state of the IA (call this "renewing" the
IA).  The renewal time is independent of the address lifetimes of any
of the lifetimes of the IPv6 addresses in the IA.  It makes most sense
for the renewal time to be less than the preferred lifetimes of all of the
IPv6 addresses in the IA, and the renewal time must be less than the
valid lifetimes or the client will lose the use of some expired
addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  If the client has an address
assocaited with an IA that is not explicitly mentioned in a message
from the server, the client leaves the address in the IA and may
continue to use the address until the lifetime for the address
expires. In any event, the server is authoritative about the set of
addresses and lifetimes in the IA.

The client must send all of the addresses associated with an IA when
renewing the IA.  The server examines this list of addresses and may
extend the lifetime or set the lifetime to zero of any addresses in
the IA.  The server may also add new addresses to the IA.  The server
returns the new IA to the client.

In all other transactions, the client sends the IA identifier and the
server returns IA identifier along with the list of addresses in the
IA.  The server is authoritative and the client simply records the IA
and configures the associated addresses.

Changes from previous summary:

* (3rd para) DHCP server does not hand out link-local addresses (input
   from Jim Bound)

* (5th para) If the server does not include an address in the IA, the
   client is allowed to continue using the address until its valid
   lifetime expires (input from Bernie Volz)


TBD:

* During the address model discussion, we noted that the current
   spec leaves the details of the renewal process to the DHCPv6 client
   implementor.  I heard consensus that we should define the renewal
   process and include it in the spec.

* We have not yet reached consensus on when the client sends the
   addresses in an IA - with every messages or only when trying to
   locate a new DHCP server (as in DHCPv4 REBINDING state)?  And, is
   the wording for sending the addresses SHOULD or MUST?

* There is still a minority position that the contents of the IA from
   the server should be authoritative, and any addresses not explicitly
   included in the IA from the server should be discarded immediately
   by the client.



From owner-dhcp-v6@bucknell.edu  Thu Oct 19 13:52:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06489;
	Thu, 19 Oct 2000 13:52:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JHoEb17799;
	Thu, 19 Oct 2000 13:50:15 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JHo1b29153
	for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 13:50:01 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05721 for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 13:49:42 -0400 (EDT)
Message-Id: <4.3.1.2.20001019134638.00b07c10@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 19 Oct 2000 13:49:10 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: client identifier 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

And here's my latest definition of the DHCPv6 client identifier.  this 
version is essentially unchanged from the previous version - I only edited 
it for brevity.  There are two TBD issues at the end of the definition.

Please review this doc and post any comments.  If we have any unresolved 
issues I'll add them to the draft for discussion at our next design team 
phone call.

- Ralph

=====
Issue: Definition of "client identifier" for DHCPv6.

Summary: IAs will be identified by a tuple: (UUID, binding-id).  UUID
is a unique identifier for a DHCP client.  All IAs from one DHCP
client share the same UUID.  A binding-id is an opaque value uniquely
identifying an IA within a client.  The client is responsible for
managing binding-ids and the protocol makes no statement about the way
in which binding-ids are formed.

The rules for selecting a UUID are:

1) If a client has previously stored a unique identifier in stable
    storage, it MUST use this for all its interfaces.

2) If a client has unique identifying information (such as a serial
    number) that it can use as a unique identifier, it MUST use this
    (after storing it in stable storage if possible).  For this to
    produce unique numbers the spec must identify the number
    space. Otherwise two boxes made by two different vendors might both
    have serial number 17.

3) If a client does not have unique identifying information and it has
    stable storage, it should generate a unique identifier by combining
    the link-layer address of one or more network interfaces, padded
    with zeros at the end to a total length of sixteen bytes, with a
    randomly generated four-byte quantity, and compute an MD5 (SHA?)
    hash over this to produce a unique identifier, and should store
    this identifier in stable storage.

4) Otherwise, the client must generate a unique identifier in a way
    that the same value is likely to be generated each time it boots,
    such as by using the link-layer address of one of their network
    interfaces as the client identifier, and MUST use the same client
    identifier for all of their interfaces.

Using a unique, permanent UUID allows a DHCP client to be positively
identified regardless of its network connections.  Identifying IAs
by (UUID, binding-id) allows a DHCP server to determine which IAs are
associated with the same DHCP client; for example, a DHCP server can
differentiate between a client that has moved to a new physical
network and a multi-homed client.  All authentication for a client is
based on the UUID, so transactions for all of a client's IAs can be
authenticated with a single key.

Changes: This summary was rewritten for brevity without changing the
   definition of the IA identifier.

TBD:
* Size and shape (number of bits, fixed or variable length) of UUID
   and binding-id.

   We have one suggestion for the format of a UUID: Length again might
   best be variable (up to some upper bound). I think the format should
   be something like a byte or word for a type of UUID, followed by one
   or more fields depending on how the UUID was generated. For example,
   if a serial number were used, these fields might consist of a
   hardware type id followed by the serial number. Now, of course, it
   would be best to use some sort of hash over this such that the data
   is not meaningful to anyone to pull out these values easily.

* How to detect and respond to UUID collisions.  In the event that two
   DHCP clients choose the same UUID, and given that we don't want to
   include the network prefix as part of the IA identifier, the server
   may assign the same internet address to two different clients.



From owner-dhcp-v6@bucknell.edu  Thu Oct 19 15:44:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27485;
	Thu, 19 Oct 2000 15:44:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JJXpb19191;
	Thu, 19 Oct 2000 15:33:51 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JJXYb21628
	for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 15:33:34 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-148.cisco.com [161.44.133.148]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20582 for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 15:33:09 -0400 (EDT)
Message-Id: <4.3.1.2.20001019145621.00b672a0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 19 Oct 2000 15:33:19 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Discussion: Names and semantics of messages
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

We discussed the following issue from the 8/31 phone conference without 
much progress towards consensus:

         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
         30. Why 'extensions' and not 'options'?

Arguments for leaving the names and semantics as they are in the current 
DHCPv6 draft include:

* these names correspond directly to names Neighbor
   Discovery (RFC2462) messages
* DHCPv6 draft messages don't look or act anything
   like RFC2131/RFC2132 messages
* Merged DHCPv4-DHCPv6 ("DHCPng") is future work

Arguments for using names and semantics from RFC2131/RFC2132 include:

* DHCPv6 draft message semantics are close to RFC2131 message
   semantics
* no compelling reason to change
* reusing RFC2131 names and semantics captures knowledge base
   from DHCPv4 design, deployment and operation

So, there is my summary of the current position of the discussion.  Once we 
have agreement about this level of, well, disagreement, we can pick up the 
discussion.

I'm not sure "options" vs. "extensions" has been discussed in any mailing 
list e-mail.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Oct 19 15:49:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28619;
	Thu, 19 Oct 2000 15:49:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JJn0b07998;
	Thu, 19 Oct 2000 15:49:00 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JJmpb28486
	for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 15:48:51 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2S7F>; Thu, 19 Oct 2000 15:48:35 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607120@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: Names and semantics of messages
Date: Thu, 19 Oct 2000 15:48:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I do think I agree with your summary and level of disagreement.

My views:

- Keep the message names as they are in the DHCPv6 draft. The message
formats and meanings are different and thus I think the message names should
be as well. 

- Use options. We know and "love" these (don't we?). I agree this is perhaps
on the surface contrary to what I said above regading the messages names,
but we've been talking about 16-bit options for DHCPv4 already and really
all we're changing is to use the 16-bit format. Also, per previous
discussions about carving out the DHCPv4 option space from the DHCPv6 option
space and 'reusing' the options that are the same, it is cleaner to talk
about options only - not options and extensions.


- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, October 19, 2000 3:33 PM
To: DHCPv6 discussion list
Subject: Discussion: Names and semantics of messages


We discussed the following issue from the 8/31 phone conference without 
much progress towards consensus:

         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
         30. Why 'extensions' and not 'options'?

Arguments for leaving the names and semantics as they are in the current 
DHCPv6 draft include:

* these names correspond directly to names Neighbor
   Discovery (RFC2462) messages
* DHCPv6 draft messages don't look or act anything
   like RFC2131/RFC2132 messages
* Merged DHCPv4-DHCPv6 ("DHCPng") is future work

Arguments for using names and semantics from RFC2131/RFC2132 include:

* DHCPv6 draft message semantics are close to RFC2131 message
   semantics
* no compelling reason to change
* reusing RFC2131 names and semantics captures knowledge base
   from DHCPv4 design, deployment and operation

So, there is my summary of the current position of the discussion.  Once we 
have agreement about this level of, well, disagreement, we can pick up the 
discussion.

I'm not sure "options" vs. "extensions" has been discussed in any mailing 
list e-mail.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Oct 19 16:28:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05359;
	Thu, 19 Oct 2000 16:28:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JKPnb04452;
	Thu, 19 Oct 2000 16:25:49 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JKPhb22112
	for <dhcp-v6@bucknell.edu>; Thu, 19 Oct 2000 16:25:43 -0400 (EDT)
Received: from kkinnear-nt (ch2-dhcp133-101.cisco.com [161.44.133.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA27218; Thu, 19 Oct 2000 16:25:27 -0400 (EDT)
Message-Id: <4.2.0.58.20001019161654.01c4e180@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 19 Oct 2000 16:26:17 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: RE: Discussion: Names and semantics of messages
Cc: kkinnear@cisco.com
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607120@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 03:48 PM 10/19/00 -0400, Bernie Volz wrote:
>I do think I agree with your summary and level of disagreement.
>
>My views:
>
>- Keep the message names as they are in the DHCPv6 draft. The message
>formats and meanings are different and thus I think the message names should
>be as well. 

         I would agree if the question was just about the message
         names, but as I read Ralph's email the issue is also
         about semantics:

Arguments for using names and semantics from RFC2131/RFC2132 include:
                               ^^^^^^^^^
* DHCPv6 draft message semantics are close to RFC2131 message
    semantics
* no compelling reason to change
* reusing RFC2131 names and semantics captures knowledge base
    from DHCPv4 design, deployment and operation
         
         If indeed the semantics are similar enough that we can
         make them essentially identical (or a clean extension),
         then we would be foolish indeed to make them needlessly
         different.

         Reusing the existing RFC2131 semantics (and thus the
         names) would yield enormous dividends across a wide swath
         of the industry, from tech support to sniffer vendors,
         from training to marketing -- to say nothing of making
         the implementation job much more straightforward.

         If we *can* reuse (and perhaps extend cleanly) the
         existing RFC2131 semantics (and thus the names) we *must*
         consider doing it!  I think the discussion should be
         centered on whether we *can* do this.

         Cheers -- Kim

[...]


>- Bernie Volz
>
>-----Original Message-----
>From: Ralph Droms [mailto:rdroms@cisco.com]
>Sent: Thursday, October 19, 2000 3:33 PM
>To: DHCPv6 discussion list
>Subject: Discussion: Names and semantics of messages
>
>
>We discussed the following issue from the 8/31 phone conference without 
>much progress towards consensus:
>
>          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
>          30. Why 'extensions' and not 'options'?
>
>Arguments for leaving the names and semantics as they are in the current 
>DHCPv6 draft include:
>
>* these names correspond directly to names Neighbor
>    Discovery (RFC2462) messages
>* DHCPv6 draft messages don't look or act anything
>    like RFC2131/RFC2132 messages
>* Merged DHCPv4-DHCPv6 ("DHCPng") is future work
>
>Arguments for using names and semantics from RFC2131/RFC2132 include:
>
>* DHCPv6 draft message semantics are close to RFC2131 message
>    semantics
>* no compelling reason to change
>* reusing RFC2131 names and semantics captures knowledge base
>    from DHCPv4 design, deployment and operation
>
>So, there is my summary of the current position of the discussion.  Once we 
>have agreement about this level of, well, disagreement, we can pick up the 
>discussion.
>
>I'm not sure "options" vs. "extensions" has been discussed in any mailing 
>list e-mail.
>
>- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Oct 20 07:31:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22365;
	Fri, 20 Oct 2000 07:31:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KBO4b19980;
	Fri, 20 Oct 2000 07:24:05 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KBNwb14896
	for <dhcp-v6@bucknell.edu>; Fri, 20 Oct 2000 07:23:58 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 53BA5431A; Fri, 20 Oct 2000 06:23:37 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 68413429F
	for <dhcp-v6@bucknell.edu>; Fri, 20 Oct 2000 06:23:33 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id HAA0000777072; Fri, 20 Oct 2000 07:23:15 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010201123.HAA0000777072@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-reply-to: Your message of "Thu, 19 Oct 2000 13:49:10 EDT."
             <4.3.1.2.20001019134638.00b07c10@mail.bucknell.edu> 
Date: Fri, 20 Oct 2000 07:23:15 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

On client identifier I posted mail why the network prefix should
be used with the client identifier and have seen no response.
this is the architecture in the present spec.  Can we have discussion
and debate on this per my mail.  As removing that feature from
dhcpv6 wil be a big negative for this solution.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Oct 20 08:52:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03687;
	Fri, 20 Oct 2000 08:52:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KCdfb31078;
	Fri, 20 Oct 2000 08:39:41 -0400 (EDT)
Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KCdOb14442
	for <dhcp-v6@bucknell.edu>; Fri, 20 Oct 2000 08:39:24 -0400 (EDT)
Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA05030
	for <dhcp-v6@bucknell.edu>; Fri, 20 Oct 2000 08:39:24 -0400 (EDT)
Date: Fri, 20 Oct 2000 08:39:24 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010201123.HAA0000777072@anw.zk3.dec.com>
Message-ID: <Pine.GSO.4.03.10010200829480.5010-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

On Fri, 20 Oct 2000, Jim Bound wrote:
> On client identifier I posted mail why the network prefix should
> be used with the client identifier and have seen no response.
> this is the architecture in the present spec.  Can we have discussion
> and debate on this per my mail.  As removing that feature from
> dhcpv6 wil be a big negative for this solution.

I think that adding the prefix to the UUID leaves us with the same problem
we have in DHCPv4 today - we can't differentiate between a host that moves
from one link to another and a multi-homed host.

Suppose a DHCP server receives a request for IA (P1, UUID0, binding-id0)
and then for IA (P2, UUID, binding-id1).  (I believe that we have
already decided we can't guarantee a client will always use the same
binding-id  for an interface.)  Are these requests for two different
interfaces from multi-homed client UUID0 or has client UUID0 moved from
link P1 to link P2?

Perhaps, if we could guarantee that a client would ALWAYS use the same
binding-id for an interface we could use the network prefix to dismbiguate
UUID collisions...

- Ralph




From owner-dhcp-v6@bucknell.edu  Fri Oct 20 12:32:58 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10709;
	Fri, 20 Oct 2000 12:32:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KGUPb03028;
	Fri, 20 Oct 2000 12:30:26 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KGULb17987
	for <dhcp-v6@bucknell.edu>; Fri, 20 Oct 2000 12:30:21 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02015 for <dhcp-v6@bucknell.edu>; Fri, 20 Oct 2000 12:30:06 -0400 (EDT)
Message-Id: <4.3.1.2.20001020122846.00b8ce60@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 20 Oct 2000 12:30:15 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC163@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Here's my summary of consensus on DHCPv6 relay agent function...

Issue:

         23. Relay agents - adopt DHCPv4 function: relay agents insert
             interface address in 'giaddr' and forward to DHCP servers
         26. Relay agents should simply encapsulate the client message
             in a DHCPv6 extension; the relay message should have its
             own type.

DHCPv6 relay agents will forward messages beetween clients and servers
using "DHCP-in-DHCP encapsulation".

Forwarding messages from clients to servers:

The relay agent creates a new DHCP message and encapsulates the entire
DHCP message from the client in a "Relayed Data" option in this new
message.  The relay agent may also add other options (an example from
DHCPv4 would be the "relay agent information" option) and may use DHCP
authentication.  The relay agent then sends the new message to the
destinations in the relay agent's forwarding list.

This mechanism is applied recursively if a relay agent forwards a
message to another relay agent; the second relay agent encapsulates
the received relay agent message (which, in turn, contains the
encapsulated message from the client) and forwards the new message to
its list of destinations.

The server unwraps each of the encapsulated messages to recover the
original client message.  The server must record the information from
each of the relay agents so it can properly form the response to the
client.  The server processes the client message and any agent options
from the encapsulating messages.

Forwarding from a server to a client:

The server first forms the response message to the client.  Then, the
server wraps that message in encapsulating message(s) to the relay
agent(s) that forwarded the original client message.  For example, if
client C's message had been forwarded through relay agents R1 and R2,
the server would form a message to R2 that carried an encapsulated
message for R1, which would in turn carry an encapsulated message for
C.

The server includes any responses to the relay agent(s) and uses
appropriate authentication for each of the encapsulated messages.



From owner-dhcp-v6@bucknell.edu  Sat Oct 21 16:57:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24031;
	Sat, 21 Oct 2000 16:57:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9LKs8b15791;
	Sat, 21 Oct 2000 16:54:08 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9LKs1b06885
	for <dhcp-v6@bucknell.edu>; Sat, 21 Oct 2000 16:54:01 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00581
	for <dhcp-v6@bucknell.edu>; Sat, 21 Oct 2000 13:54:00 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA27906
	for <dhcp-v6@bucknell.edu>; Sat, 21 Oct 2000 13:54:00 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9LKrxf734876
	for <dhcp-v6@bucknell.edu>; Sat, 21 Oct 2000 13:53:59 -0700 (PDT)
Date: Fri, 20 Oct 2000 16:42:36 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: RE: DHCPv6 Relay Changes
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <4.3.1.2.20001020122846.00b8ce60@mail.bucknell.edu>
Message-ID: <Roam.SIMC.2.0.6.972085356.22820.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> DHCPv6 relay agents will forward messages beetween clients and servers
> using "DHCP-in-DHCP encapsulation".

If the configuration of the relay(s) is incorrect, you could potential
end up with recursive encapsulation.
It would probably make sense to prevent this e.g. with an upper bound on
the message size.

  Erik



From owner-dhcp-v6@bucknell.edu  Sun Oct 22 09:01:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14144;
	Sun, 22 Oct 2000 09:01:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9MCwLb02194;
	Sun, 22 Oct 2000 08:58:21 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9MCw4b32279
	for <dhcp-v6@bucknell.edu>; Sun, 22 Oct 2000 08:58:05 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VJWD9R1S>; Sun, 22 Oct 2000 08:57:49 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE860360713F@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Sun, 22 Oct 2000 08:57:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>* We have not yet reached consensus on when the client sends the
>   addresses in an IA - with every messages or only when trying to
>   locate a new DHCP server (as in DHCPv4 REBINDING state)?  And, is
>   the wording for sending the addresses SHOULD or MUST?

While it may be premature as there's been no (or relatively little)
discussion regarding the possibility of giving clients a multicast address
as the server's address, I think it best for sending the addresses in an IA
to be a MUST.

For things like redundancy, whether a 'revised' DHCPv4 Failover protocol or
something else, the idea of having a client send DHCPv6 requests (whether
initial, renewal, or rebinding) to a multicast address instead of a unicast
address is attractive. Thus, having the client provide the address list to
the server is critical (since the redundancy model may rely on lazy updates
or perhaps even no updates).

I guess an alterative is to add the requirement that only if the destination
address for a message is a multicast address, it is a MUST (instead of
always a MUST).

Other benefits for always requiring the sending is that it makes debugging
and tracing easier (since a rebinding or renewal may come days after the
initial request and being able to compare the Request against the Reply
without having to know what the client and server knew is attractive).

The COST of having this be a MUST is the increase in packet size and
processing time at the receiver - a relatively small price to pay. If that
price is to high in certain applications (wireless?), perhaps a solution is
for an option (extension) to be defined that tells the client that it is OK
not to send the addresses for specific cases. The cost of that option is 4
or 5 bytes (5 with a flag byte for on/off). Though there are likely some
issues with this option - such as scoping (when does it apply/not apply).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Thursday, October 19, 2000 1:16 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


Here's my latest summary of the DHCPv6 address model.  I've included a 
summary of changes from the previous model and  a list of 3 TBD issues at 
the end of the summary.

Please review this summary and post any comments.  If we have any 
unresolved issues I'll add them to the draft for discussion at our next 
design team phone call.

- Ralph

=====

Issue: DHCPv6 address model.  Here's my summary of the discussion:

DHCP clients and servers will use Identity Associations (IAs) to
manage IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in
protocol messages.

Each IPv6 address has an associated preferred and valid lifetime.  The
lifetimes are determined by the server and handed to the client.
There are no restrictions on the scopes or number of IPv6 addresses in
an IA; an IA might contain just one IPv6 address or it might contain a
collection of global- and  site-local addresses.

The renewal time defines the time at which the client must contact the
server to get the current state of the IA (call this "renewing" the
IA).  The renewal time is independent of the address lifetimes of any
of the lifetimes of the IPv6 addresses in the IA.  It makes most sense
for the renewal time to be less than the preferred lifetimes of all of the
IPv6 addresses in the IA, and the renewal time must be less than the
valid lifetimes or the client will lose the use of some expired
addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  If the client has an address
assocaited with an IA that is not explicitly mentioned in a message
from the server, the client leaves the address in the IA and may
continue to use the address until the lifetime for the address
expires. In any event, the server is authoritative about the set of
addresses and lifetimes in the IA.

The client must send all of the addresses associated with an IA when
renewing the IA.  The server examines this list of addresses and may
extend the lifetime or set the lifetime to zero of any addresses in
the IA.  The server may also add new addresses to the IA.  The server
returns the new IA to the client.

In all other transactions, the client sends the IA identifier and the
server returns IA identifier along with the list of addresses in the
IA.  The server is authoritative and the client simply records the IA
and configures the associated addresses.

Changes from previous summary:

* (3rd para) DHCP server does not hand out link-local addresses (input
   from Jim Bound)

* (5th para) If the server does not include an address in the IA, the
   client is allowed to continue using the address until its valid
   lifetime expires (input from Bernie Volz)


TBD:

* During the address model discussion, we noted that the current
   spec leaves the details of the renewal process to the DHCPv6 client
   implementor.  I heard consensus that we should define the renewal
   process and include it in the spec.

* We have not yet reached consensus on when the client sends the
   addresses in an IA - with every messages or only when trying to
   locate a new DHCP server (as in DHCPv4 REBINDING state)?  And, is
   the wording for sending the addresses SHOULD or MUST?

* There is still a minority position that the contents of the IA from
   the server should be authoritative, and any addresses not explicitly
   included in the IA from the server should be discarded immediately
   by the client.



From owner-dhcp-v6@bucknell.edu  Sun Oct 22 09:02:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14602;
	Sun, 22 Oct 2000 09:02:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9MD2eb00075;
	Sun, 22 Oct 2000 09:02:40 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9MD2Tb01262
	for <dhcp-v6@bucknell.edu>; Sun, 22 Oct 2000 09:02:29 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VJWD9R14>; Sun, 22 Oct 2000 09:02:14 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607140@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Sun, 22 Oct 2000 09:02:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Excellent point. Or perhaps limit the number of hops allowed? Perhaps a
solution is to have a relay add a hop count option and other relays to
increment (or decrement) this. Once the limit is exceeded, the packet is
dropped.

Note that subsequent relays may add little, if anything, to the packets
since there may be little need for them to encapsulate (though I believe
we're assuming at present that all relays would encapsulate?).

- Bernie Volz

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
Sent: Friday, October 20, 2000 7:43 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 Relay Changes



> DHCPv6 relay agents will forward messages beetween clients and servers
> using "DHCP-in-DHCP encapsulation".

If the configuration of the relay(s) is incorrect, you could potential
end up with recursive encapsulation.
It would probably make sense to prevent this e.g. with an upper bound on
the message size.

  Erik



From owner-dhcp-v6@bucknell.edu  Sun Oct 22 22:27:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27299;
	Sun, 22 Oct 2000 22:27:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9N2I4b06270;
	Sun, 22 Oct 2000 22:18:04 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9N2Hsb14472
	for <dhcp-v6@bucknell.edu>; Sun, 22 Oct 2000 22:17:54 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 1EEEC8CFE; Sun, 22 Oct 2000 22:17:38 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 04BBD9637; Sun, 22 Oct 2000 22:17:38 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000629672; Sun, 22 Oct 2000 22:17:18 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010230217.WAA0000629672@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: kkinnear@cisco.com
Subject: Re: Discussion: Names and semantics of messages 
In-reply-to: Your message of "Thu, 19 Oct 2000 16:26:17 EDT."
             <4.2.0.58.20001019161654.01c4e180@funnel.cisco.com> 
Date: Sun, 22 Oct 2000 22:17:18 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Kim,


         I would agree if the question was just about the message
         names, but as I read Ralph's email the issue is also
         about semantics:

>Arguments for using names and semantics from RFC2131/RFC2132 include:

I agree and the semantics of solicit, advertise are completely different
than OFFER and I think also has optimizations over DHCPv4.

         If indeed the semantics are similar enough that we can
         make them essentially identical (or a clean extension),
         then we would be foolish indeed to make them needlessly
         different.

They are not similar or even close semantically or their behavior.

         Reusing the existing RFC2131 semantics (and thus the
         names) would yield enormous dividends across a wide swath
         of the industry, from tech support to sniffer vendors,
         from training to marketing -- to say nothing of making
         the implementation job much more straightforward.

Not if the semantics are different and that will cause pain in fact if
they are different they should be different.  And they are not the same.

         If we *can* reuse (and perhaps extend cleanly) the
         existing RFC2131 semantics (and thus the names) we *must*
         consider doing it!  I think the discussion should be
         centered on whether we *can* do this.

I don't agree.  What we have designed will work as messages and within a
transaction based architecture which dhcpv6 is.  Also I would argue our
objective is to get a draft out and I think a bit more than it will feel
better is a reason to change the dhcpv6 messages.

I would like to hear technical and architectural reasons why some other
message type than the ones we have will work better.  

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Sun Oct 22 22:43:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29884;
	Sun, 22 Oct 2000 22:43:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9N2gcb07216;
	Sun, 22 Oct 2000 22:42:38 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9N2gVb23282
	for <dhcp-v6@bucknell.edu>; Sun, 22 Oct 2000 22:42:31 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 95B151447; Sun, 22 Oct 2000 21:42:15 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id E6E131696
	for <dhcp-v6@bucknell.edu>; Sun, 22 Oct 2000 21:42:14 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000632144; Sun, 22 Oct 2000 22:42:12 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010230242.WAA0000632144@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Discussion: client identifier 
In-reply-to: Your message of "Fri, 20 Oct 2000 08:39:24 EDT."
             <Pine.GSO.4.03.10010200829480.5010-100000@leo> 
Date: Sun, 22 Oct 2000 22:42:11 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> On client identifier I posted mail why the network prefix should
>> be used with the client identifier and have seen no response.
>> this is the architecture in the present spec.  Can we have discussion
>> and debate on this per my mail.  As removing that feature from
>> dhcpv6 wil be a big negative for this solution.

>I think that adding the prefix to the UUID leaves us with the same problem
>we have in DHCPv4 today - we can't differentiate between a host that moves
>from one link to another and a multi-homed host.

True.  But for stationary hosts it works fine.  We could use the Mobile
IPv6 Binding Update option to notify a move in prefix too?  I don't
think we should sacrafice stationary hosts management for mobile host
management at all as a design center.  Also if the client releases their
addresses when they leave a link the prefix still works or will just
time out.

I also have no faith we will define a UUID that will work across a site
let alone the Internet any better than we did in IPv6 for 5 years.

>Suppose a DHCP server receives a request for IA (P1, UUID0, binding-id0)
>and then for IA (P2, UUID, binding-id1).  (I believe that we have
>already decided we can't guarantee a client will always use the same
>binding-id  for an interface.)  Are these requests for two different
>interfaces from multi-homed client UUID0 or has client UUID0 moved from
>link P1 to link P2?

The binding-id will not matter and can even be duplicated (hopefully it
won't be) as long as UUIDs are not permitted to be duplicated on a link?

It does not matter as my example in my mail the database at the server
is basing the entry based on an aggregate of Prefix+UUID+binding-id.
That aggregate will work for a search and for management of the client
parameters.  It won't matter if the node is multihomed or on a different
link and be transparent to the server as long as the binding-ids are not
duplicated in the case where the UUID is two NICs on one link.  In that
case I would argue that either the UUIDs or binding-ids must be
different.

>Perhaps, if we could guarantee that a client would ALWAYS use the same
>binding-id for an interface we could use the network prefix to dismbiguate
>UUID collisions...

Thats where I went above too.
Well we need to think about that for sure.  I think that would be wise.
IPv6 had the same architecture reasons for not permitting a client to
use the same link-local address on a link that we should not want a
client to duplicate a UUID or binding-id on the same link. 

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 06:47:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19713;
	Mon, 23 Oct 2000 06:47:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NAfkb04367;
	Mon, 23 Oct 2000 06:41:46 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NAfgb25081
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 06:41:42 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA09820
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 06:40:57 -0400
Message-Id: <200010231040.GAA09820@hygro.adsl.duke.edu>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Fri, 20 Oct 2000 12:30:15 EDT." <4.3.1.2.20001020122846.00b8ce60@mail.bucknell.edu> 
Date: Mon, 23 Oct 2000 06:40:57 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

What is the benefit in allowing recursive enacapsulation through
multiple relay agents? Would it make sense to simplify things and
simply say there can be at most one relay agent in the path, and the
relay agent always forwards the packet to a DHCP server (or an entity
that looks like the server from a protocol perspective)?

Thomas



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 06:55:30 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22032;
	Mon, 23 Oct 2000 06:55:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NAt1b06724;
	Mon, 23 Oct 2000 06:55:01 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NAslb24033
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 06:54:47 -0400 (EDT)
Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA06749
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 06:54:47 -0400 (EDT)
Date: Mon, 23 Oct 2000 06:54:47 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: <200010231040.GAA09820@hygro.adsl.duke.edu>
Message-ID: <Pine.GSO.4.03.10010230652290.6740-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

On Mon, 23 Oct 2000, Thomas Narten wrote:
> What is the benefit in allowing recursive enacapsulation through
> multiple relay agents? Would it make sense to simplify things and
> simply say there can be at most one relay agent in the path, and the
> relay agent always forwards the packet to a DHCP server (or an entity
> that looks like the server from a protocol perspective)?

Oops.  I've been looking at relay agents with my DHCPv4 hat on.  In
DHCPv6, the relay agent forwards messages to a multicast group that
includes all DHCP servers.  So, a relay agent will always forward DHCP
messages directly to a DHCP server...

- Ralph




From owner-dhcp-v6@bucknell.edu  Mon Oct 23 09:38:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02835;
	Mon, 23 Oct 2000 09:38:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NDYSb00326;
	Mon, 23 Oct 2000 09:34:28 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NDXsb10633
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 09:33:54 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VJWD9RS1>; Mon, 23 Oct 2000 09:33:35 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607141@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Mon, 23 Oct 2000 09:33:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

While one could require that the outer most relays know all, I think it
would be appropriate to allow forwarding toward the inner relays (to the
final server). This allows for far simplier configuration of devices as you
move out from the core of the network.

It likely also has some benefits in terms of firewalls and the like. 

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Monday, October 23, 2000 6:41 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 Relay Changes


What is the benefit in allowing recursive enacapsulation through
multiple relay agents? Would it make sense to simplify things and
simply say there can be at most one relay agent in the path, and the
relay agent always forwards the packet to a DHCP server (or an entity
that looks like the server from a protocol perspective)?

Thomas



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 14:24:31 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26655;
	Mon, 23 Oct 2000 14:24:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NILJb14395;
	Mon, 23 Oct 2000 14:21:19 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NILDb16552
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 14:21:13 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24784 for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 14:20:54 -0400 (EDT)
Message-Id: <4.3.1.2.20001023104537.00b48b80@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 23 Oct 2000 14:18:45 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010230242.WAA0000632144@anw.zk3.dec.com>
References: <Your message of "Fri, 20 Oct 2000 08:39:24 EDT." <Pine.GSO.4.03.10010200829480.5010-100000@leo>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 10:42 PM 10/22/00 -0400, you wrote:

>True.  But for stationary hosts it works fine.  We could use the Mobile
>IPv6 Binding Update option to notify a move in prefix too?  I don't
>think we should sacrafice stationary hosts management for mobile host
>management at all as a design center.

I was thinking more of "relatively stationary" hosts - say, a desktop PC 
that happens to move to a new office.  I think Ted has expressed (and I'm 
speaking for him here knowing that he's off-line for a couple of weeks) 
concern about prefix-based identifiers based on his experience with the ISC 
DHCP server:

>From: Ted Lemon <mellon@nominum.com>
>Date: Wed, 06 Sep 2000 12:01:17 -0700
>I am trying to get away from the notion that an IP address is uniquely
>identified by {client identifier, physical network}.   This causes
>lots of obnoxious ambiguity in RFC2131 that I don't think adds any
>value - to correctly implement the protocol, I have to allow clients
>to have active leases with the same client identifier on different
>physical networks at the same time, which means that when a client
>moves from physical network to physical network within the same
>administrative domain, the server may wind up with active leases for
>that client on more than one network when the client is only connected
>to one network.   Having one identity association per network
>interface avoids this problem - if you are multiply attached, you'll
>have multiple identity associations, and if you're singly attached, I
>can nuke your old lease when you change networks.

Ted's observation was the basis for my example:

> >Suppose a DHCP server receives a request for IA (P1, UUID0, binding-id0)
> >and then for IA (P2, UUID0, binding-id1).  (I believe that we have
> >already decided we can't guarantee a client will always use the same
> >binding-id  for an interface.)  Are these requests for two different
> >interfaces from multi-homed client UUID0 or has client UUID0 moved from
> >link P1 to link P2?
>
>The binding-id will not matter and can even be duplicated (hopefully it
>won't be) as long as UUIDs are not permitted to be duplicated on a link?

If the binding-id is duplicated, and the requests come reasonably close 
together in time, the server *might* be able to deduce that UUID0 is not a 
dual-homed host.  But, if the binding-ids are different, either UUID0 is a 
dual-homed host or it moved to a new subnet and renumbered its interfaces.

>It does not matter as my example in my mail the database at the server
>is basing the entry based on an aggregate of Prefix+UUID+binding-id.
>That aggregate will work for a search and for management of the client
>parameters.  It won't matter if the node is multihomed or on a different
>link and be transparent to the server as long as the binding-ids are not
>duplicated in the case where the UUID is two NICs on one link.  In that
>case I would argue that either the UUIDs or binding-ids must be
>different.

But, Ted expressed a concern and I've given an example - using a common 
case in which a relatively stationary client moves to a new subnet - where 
including the prefix causes a specific problem.   So, I can't agree with 
your claim that prefix+UID+binding-id is sufficient...

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 15:42:33 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14545;
	Mon, 23 Oct 2000 15:42:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NJdeb28298;
	Mon, 23 Oct 2000 15:39:40 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NJdbb31290
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 15:39:37 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VJWD9SGZ>; Mon, 23 Oct 2000 15:39:22 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607146@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Mon, 23 Oct 2000 15:39:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>I've been looking at relay agents with my DHCPv4 hat on.  In
>DHCPv6, the relay agent forwards messages to a multicast group that
>includes all DHCP servers.

Well, this is technically INCORRECT. My reading of the specification says
that DHCPv6 relays may forward using a number of mechanisms:
	- some combination of the FF05::1:3 (All Servers) site-local
multicast address
	- some other (perhaps a combination) of site-local multicast
addresses set up within the DHCP domain to include the servers in that
domain
	- or a list of unicast addresses for servers
(See section 8.3).

So, in this respect I think DHCPv6 relays are similar to DHCPv4 relays -
just that Multicast can be used instead of necessarily having to
pre-configure a relay with full server information.

The text doesn't explicitly allow for relay chaining (at least that I could
find).

- Bernie

-----Original Message-----
From: Ralph E. Droms [mailto:droms@bucknell.edu]
Sent: Monday, October 23, 2000 6:55 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 Relay Changes


On Mon, 23 Oct 2000, Thomas Narten wrote:
> What is the benefit in allowing recursive enacapsulation through
> multiple relay agents? Would it make sense to simplify things and
> simply say there can be at most one relay agent in the path, and the
> relay agent always forwards the packet to a DHCP server (or an entity
> that looks like the server from a protocol perspective)?

Oops.  I've been looking at relay agents with my DHCPv4 hat on.  In
DHCPv6, the relay agent forwards messages to a multicast group that
includes all DHCP servers.  So, a relay agent will always forward DHCP
messages directly to a DHCP server...

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 16:57:46 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23356;
	Mon, 23 Oct 2000 16:57:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NKsdb00311;
	Mon, 23 Oct 2000 16:54:39 -0400 (EDT)
Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NKsGb03744
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 16:54:17 -0400 (EDT)
Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA07034
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 16:54:16 -0400 (EDT)
Date: Mon, 23 Oct 2000 16:54:16 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607146@lespaul.process.com>
Message-ID: <Pine.GSO.4.03.10010231651410.7022-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Whoops, That's what I get for answering from memory rather than reading
the spec.

In any event, we could make a design decision to disallow relay agent
chaining...


On Mon, 23 Oct 2000, Bernie Volz wrote:

> >I've been looking at relay agents with my DHCPv4 hat on.  In
> >DHCPv6, the relay agent forwards messages to a multicast group that
> >includes all DHCP servers.
> 
> Well, this is technically INCORRECT. My reading of the specification says
> that DHCPv6 relays may forward using a number of mechanisms:
> 	- some combination of the FF05::1:3 (All Servers) site-local
> multicast address
> 	- some other (perhaps a combination) of site-local multicast
> addresses set up within the DHCP domain to include the servers in that
> domain
> 	- or a list of unicast addresses for servers
> (See section 8.3).
> 
> So, in this respect I think DHCPv6 relays are similar to DHCPv4 relays -
> just that Multicast can be used instead of necessarily having to
> pre-configure a relay with full server information.
> 
> The text doesn't explicitly allow for relay chaining (at least that I could
> find).

- Ralph




From owner-dhcp-v6@bucknell.edu  Mon Oct 23 17:38:36 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28054;
	Mon, 23 Oct 2000 17:38:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NLaBb08366;
	Mon, 23 Oct 2000 17:36:11 -0400 (EDT)
Received: from mail01.phoenixdsl.com (mail01.phoenixdsl.com [216.178.151.7])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NLZwb20159
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 17:35:58 -0400 (EDT)
Received: from rdroms-nt.cisco.com ([64.6.163.243])
          by mail01.phoenixdsl.com
          (InterMail vK.4.02.00.05.01 201-232-116-105-101 license da4da6e5fc829a7858725236bede8deb)
          with ESMTP
          id <20001023213557.UIPG2557.mail01@rdroms-nt.cisco.com>;
          Mon, 23 Oct 2000 16:35:57 -0500
Message-Id: <4.3.1.2.20001023171008.00af5740@mail.bucknell.edu>
X-Sender: rdroms@mail.phoenixdsl.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 23 Oct 2000 17:36:01 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: Discussion: Names and semantics of messages 
Cc: kkinnear@cisco.com
In-Reply-To: <200010230217.WAA0000629672@anw.zk3.dec.com>
References: <Your message of "Thu, 19 Oct 2000 16:26:17 EDT." <4.2.0.58.20001019161654.01c4e180@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Before I respond to Jim's comments, let me make it clear that I am writing 
as a technical contributor, not as document editor.  Also let me point out 
that, as technical contributor, I may chime in with opinions that differ 
from Jim and Mike's.  Regardless of those inputs, I will make every effort 
in my role as document editor to capture the consensus of the WG.

At 10:17 PM 10/22/00 -0400, Jim Bound wrote:

>          If indeed the semantics are similar enough that we can
>          make them essentially identical (or a clean extension),
>          then we would be foolish indeed to make them needlessly
>          different.
>
>They are not similar or even close semantically or their behavior.

We need to consider the fundamental requirements of the client-server 
message exchanges over and above their definition in the current DHCPv6 
draft spec.  Certainly, there are differences between the semantics (and 
names) of the DHCPv6 messages and the RFC2131 messages.  But, are those 
differences inherent in the

>          Reusing the existing RFC2131 semantics (and thus the
>          names) would yield enormous dividends across a wide swath
>          of the industry, from tech support to sniffer vendors,
>          from training to marketing -- to say nothing of making
>          the implementation job much more straightforward.
>
>Not if the semantics are different and that will cause pain in fact if
>they are different they should be different.  And they are not the same.

Jim, we disagree about this point.  In an earlier message to this list 
(Subject: Re: Design team teleconference, 8/31, Date: Thu, 14 Sep 2000), I 
wrote:

>For example, the DHCPv6 Solicit message now acts pretty much like the
>DHCPv4 DHCPDISCOVER message (allowing for differences in the message
>formats).  The Advertise message acts pretty much like a DHCPOFFER, except
>the Advertise doesn't include any offered parameters.  is there a reason
>for the difference or could we include parameters in the DHCPv6 message and
>call it a DHCPOFFER?

I've walked through the other DHCPv6 messages and am prepared to defend 
(although I haven't written down the details) the claim that we can reuse 
the DISCOVER/OFFER/REQUEST/ACK messages in DHCPv6.

>          If we *can* reuse (and perhaps extend cleanly) the
>          existing RFC2131 semantics (and thus the names) we *must*
>          consider doing it!  I think the discussion should be
>          centered on whether we *can* do this.
>
>I don't agree.  What we have designed will work as messages and within a
>transaction based architecture which dhcpv6 is.  Also I would argue our
>objective is to get a draft out and I think a bit more than it will feel
>better is a reason to change the dhcpv6 messages.
>
>I would like to hear technical and architectural reasons why some other
>message type than the ones we have will work better.

For me, the question is not whether some other set of messages will work 
better; rather, the question for me is whether we need to redesign the 
DHCPv4 messages and exchanges.

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 23:27:30 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18279;
	Mon, 23 Oct 2000 23:27:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9O3Opb30442;
	Mon, 23 Oct 2000 23:24:51 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9O3Oeb02429
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 23:24:40 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 181113C3F; Mon, 23 Oct 2000 23:24:25 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id B9A143EC9
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 23:24:24 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000796664; Mon, 23 Oct 2000 23:24:05 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010240324.XAA0000796664@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Discussion: client identifier 
In-reply-to: Your message of "Mon, 23 Oct 2000 14:18:45 EDT."
             <4.3.1.2.20001023104537.00b48b80@mail.bucknell.edu> 
Date: Mon, 23 Oct 2000 23:24:04 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>True.  But for stationary hosts it works fine.  We could use the Mobile
>>IPv6 Binding Update option to notify a move in prefix too?  I don't
>>think we should sacrafice stationary hosts management for mobile host
>>management at all as a design center.

>I was thinking more of "relatively stationary" hosts - say, a desktop PC 
>that happens to move to a new office.  I think Ted has expressed (and I'm 
>speaking for him here knowing that he's off-line for a couple of weeks) 
>concern about prefix-based identifiers based on his experience with the ISC 
>DHCP server:

OK.  I can follow this and did and when the host (or node) moves off a
link in IPv6 it will have a new prefix, not the same prefix.


>From: Ted Lemon <mellon@nominum.com>
>Date: Wed, 06 Sep 2000 12:01:17 -0700
>I am trying to get away from the notion that an IP address is uniquely
>identified by {client identifier, physical network}.   This causes
>lots of obnoxious ambiguity in RFC2131 that I don't think adds any
>value - to correctly implement the protocol, I have to allow clients
>to have active leases with the same client identifier on different
>physical networks at the same time, which means that when a client
>moves from physical network to physical network within the same
>administrative domain, the server may wind up with active leases for
>that client on more than one network when the client is only connected
>to one network.   Having one identity association per network
>interface avoids this problem - if you are multiply attached, you'll
>have multiple identity associations, and if you're singly attached, I
>can nuke your old lease when you change networks.

>Ted's observation was the basis for my example:

I agree with Ted's observation.  It is not the same scenario as DHCPv6
we changed the model in DHCPv6 for what the server maintains and what
the client-identifier is by definition.  In DHCPv6 the client-identifier
of DCHPv4 is:

     Prefix + Link-Local address

Link-Local is guranteed to be unique in IPv6 on a link.
Prefix is guranteed to be unique in a site (or even the Internet).

So with Ted's IA model.

Node A on Alink with-link-local of 22 with prefix 3ffe (3ffe::A::22)

and 

Node B on Blink with-link-local of 22 with prefix 4ffe (4ffe::B::22)

Node A IA = 3ffe::A::22
Node B IA = 4ffe::A::22

Now lets see what happens when Node B moves to Alink.

It enters the LAN and does DAD on its interface and finds out that 22 is
taken and must use another link-local address.  Node B does this and for
this discussion lets asssume it bumps 22 to 23 and then its
with-link-local on Alink is 23.  Now node B becomes 3ffe::A::23 and a
new client database entry in the server database.  The B client IMO should
release its resources before going to Alink, but if it does not its
entry would time out and eventually be deleted.  Or we could define a
Mobile-DHCPv6-Delete-Old-IA.  

The IA changes when you leave the subnet your on.

This supports Ted's postulate above:

>Having one identity association per network interface avoids this problem - 
>if you are multiply attached, you'll have multiple identity associations, 
>and if you're singly attached, I can nuke your old lease when you change 
>networks.

It would be nice if the client told the server they are leaving is the
discussion we still have to have and how, and what happens when it
can't.

What I describe above also supports Ted's IA model where if you have a
dual homed node on the same link it works to in IPv6.  Because each
interface would be an IA which I think is a good simple model.

Now the other part of Ted's good idea is that we trash using the
link-local address (and other input cause its tied to a NIC).  The
link-local address above is changed to the UUID + binding-ID, so now
we have prefix+UUID+binding-id.

If we state the following and can agree to it:

 1) UUIDs cannot be duplicated by hosts on a link.
 2) binding-ids for interfaces must be different on a node.

Then we can do DAD on UUID+binding-ids in IPv6 to verify they are unique
on a link for an interface. 

The UUID can still be used for security and the node can keep it if it
roams in the site.  If its UUID as it roams collides on a link with
another UUID, one of them must change, and the visiting node would have
to change as IPv6 DAD is specified today.  Then this means the node
needs to reset its security parameters.  So if the UUIDs do not collide
there is no problem and with a good algorithm for UUIDs we can be pretty
sure in a site in DHCPv6 the UUIDs won't collide across links.  But if
they do we have a mechanism to cover it.

Then Node B can move to Alink and work as in my above example.

In the above we integrate Ted's IA and UUID model right into the IPv6
architectural benefits and it will work in the present spec for DHCPv6.
I think a good and expedient solution for us.

>> >Suppose a DHCP server receives a request for IA (P1, UUID0, binding-id0)
>> >and then for IA (P2, UUID0, binding-id1).  (I believe that we have
>> >already decided we can't guarantee a client will always use the same
>> >binding-id  for an interface.)  Are these requests for two different
>> >interfaces from multi-homed client UUID0 or has client UUID0 moved from
>> >link P1 to link P2?
>>
>>The binding-id will not matter and can even be duplicated (hopefully it
>>won't be) as long as UUIDs are not permitted to be duplicated on a link?
>
>If the binding-id is duplicated, and the requests come reasonably close 
>together in time, the server *might* be able to deduce that UUID0 is not a 
>dual-homed host.  But, if the binding-ids are different, either UUID0 is a 
>dual-homed host or it moved to a new subnet and renumbered its interfaces.

I think I address this in the model above with Ted's parameters?

>>It does not matter as my example in my mail the database at the server
>>is basing the entry based on an aggregate of Prefix+UUID+binding-id.
>>That aggregate will work for a search and for management of the client
>>parameters.  It won't matter if the node is multihomed or on a different
>>link and be transparent to the server as long as the binding-ids are not
>>duplicated in the case where the UUID is two NICs on one link.  In that
>>case I would argue that either the UUIDs or binding-ids must be
>>different.

>But, Ted expressed a concern and I've given an example - using a common 
>case in which a relatively stationary client moves to a new subnet - where 
>including the prefix causes a specific problem.   So, I can't agree with 
>your claim that prefix+UID+binding-id is sufficient...

I think I addressed this further using Ted's parameters?

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Oct 23 23:29:56 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18789;
	Mon, 23 Oct 2000 23:29:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9O3Tcb03563;
	Mon, 23 Oct 2000 23:29:38 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9O3Tab11159
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 23:29:36 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id E25352C63; Mon, 23 Oct 2000 22:29:19 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 7A014150C
	for <dhcp-v6@bucknell.edu>; Mon, 23 Oct 2000 22:29:19 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000796948; Mon, 23 Oct 2000 23:29:17 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010240329.XAA0000796948@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Mon, 23 Oct 2000 16:54:16 EDT."
             <Pine.GSO.4.03.10010231651410.7022-100000@leo> 
Date: Mon, 23 Oct 2000 23:29:17 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>In any event, we could make a design decision to disallow relay agent
>chaining...

I vote for that and its a good idea.

/jim



From owner-dhcp-v6@bucknell.edu  Tue Oct 24 00:45:53 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00924;
	Tue, 24 Oct 2000 00:44:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9O4Mgb23819;
	Tue, 24 Oct 2000 00:22:43 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9O4Llb11834
	for <dhcp-v6@bucknell.edu>; Tue, 24 Oct 2000 00:22:36 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 898774312; Tue, 24 Oct 2000 00:20:41 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP
	id 49542408D; Tue, 24 Oct 2000 00:20:41 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000802876; Tue, 24 Oct 2000 00:20:39 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010240420.AAA0000802876@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: kkinnear@cisco.com, bound@ZK3.DEC.COM
Subject: Re: Discussion: Names and semantics of messages 
In-reply-to: Your message of "Mon, 23 Oct 2000 17:36:01 EDT."
             <4.3.1.2.20001023171008.00af5740@mail.bucknell.edu> 
Date: Tue, 24 Oct 2000 00:20:38 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>          If indeed the semantics are similar enough that we can
>>          make them essentially identical (or a clean extension),
>>          then we would be foolish indeed to make them needlessly
>>          different.
>>
>>They are not similar or even close semantically or their behavior.

>We need to consider the fundamental requirements of the client-server 
>message exchanges over and above their definition in the current DHCPv6 
>draft spec.  Certainly, there are differences between the semantics (and 
>names) of the DHCPv6 messages and the RFC2131 messages.  But, are those 
>differences inherent in the

Not sure if my mail trashed the last part of your sentence?  I will
respond to parts below as the last part of this could say different
things.

>>          Reusing the existing RFC2131 semantics (and thus the
>>          names) would yield enormous dividends across a wide swath
>>          of the industry, from tech support to sniffer vendors,
>>          from training to marketing -- to say nothing of making
>>          the implementation job much more straightforward.
>>
>>Not if the semantics are different and that will cause pain in fact if
>>they are different they should be different.  And they are not the same.
>
>Jim, we disagree about this point.  In an earlier message to this list 
>(Subject: Re: Design team teleconference, 8/31, Date: Thu, 14 Sep 2000), I 
>wrote:

>>For example, the DHCPv6 Solicit message now acts pretty much like the
>>DHCPv4 DHCPDISCOVER message (allowing for differences in the message
>>formats).  The Advertise message acts pretty much like a DHCPOFFER, except
>>the Advertise doesn't include any offered parameters.  is there a reason
>>for the difference or could we include parameters in the DHCPv6 message and
>>call it a DHCPOFFER?

>I've walked through the other DHCPv6 messages and am prepared to defend 
>(although I haven't written down the details) the claim that we can reuse 
>the DISCOVER/OFFER/REQUEST/ACK messages in DHCPv6.

The solicit below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 1 |C|P|  reserved |  prefix-len |   solicit-ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+o

The "C" bit will be gone I believe from consensus (just use release).

The "P" bit says return me a list of prefixes.  

The prefix-len tells the server the relays bits in the prefix.  

The solicit ID permits the client to differentiate between servers using
a different solicit ID we permit per input on previous draft.

The Solicit message is Multicast.

The Solicit does not let a client suggest addresses as in DHCPDISCOVER.

If we look at a solicit vs a DHCPDISCOVER on a datascope or tcpdump they
look completely different and are not identifiable.

The purpose of it is as a DHCPDISCOVER with new features.  Solicit is
the terminology in ND and addrconf and the messages do not have the same
content and therefore I believe they should be different. 

Advertise:

     0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 2 |  reserved   |   solicit-ID    |  preference   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              extensions (variable number and length) ...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Provides solicit-id to the client.
Provides preference value to client.
But note it does permit extensions.
Again Advertise is used in ND and addrconf.

I don't see the added value at all of making them the same as DHCPv4?

>>          If we *can* reuse (and perhaps extend cleanly) the
>>          existing RFC2131 semantics (and thus the names) we *must*
>>          consider doing it!  I think the discussion should be
>>          centered on whether we *can* do this.
>>
>>I don't agree.  What we have designed will work as messages and within a
>>transaction based architecture which dhcpv6 is.  Also I would argue our
>>objective is to get a draft out and I think a bit more than it will feel
>>better is a reason to change the dhcpv6 messages.
>>
>>I would like to hear technical and architectural reasons why some other
>>message type than the ones we have will work better.
>
>For me, the question is not whether some other set of messages will work 
>better; rather, the question for me is whether we need to redesign the 
>DHCPv4 messages and exchanges.

I don't think so. DHCPv4 works with IPv4 fine and the messages are
appropriate.  DHCPv6 needs to work with IPv6 and the messages are
appropriate, and have continuity with ND and addrconf which is the
engineering  goal, so DHCPv6 interoperates efficiently with addrconf and
I could use Kim's argument for keeping them by saying operators will
become use to solicit and advertise with IPv6 and having them be discover
and offer is not congruent for IPv6 operators.  And at some point IPv4
will go away and in fact some customers will use IPv6 and DHCPv6 on
networks and not use DHCPv4 or other IPv4 thingees that will need DHCPv6
(e.g. 3GPP Mobile IPv6 networks).

Bernie also did not want to change them and may have other input too.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Tue Oct 24 16:06:45 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26877;
	Tue, 24 Oct 2000 16:06:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9OK3vb00256;
	Tue, 24 Oct 2000 16:03:57 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9OK3rb00042
	for <dhcp-v6@bucknell.edu>; Tue, 24 Oct 2000 16:03:53 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VRHK088G>; Tue, 24 Oct 2000 16:03:37 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE860360715C@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: kkinnear@cisco.com
Subject: RE: Discussion: Names and semantics of messages
Date: Tue, 24 Oct 2000 16:03:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>Bernie also did not want to change them and may have other input too.

Oh, when don't I have input???

If we wanted to switch the DHCPv6 messages to be more like DHCPv4 messages,
we'd have to have the DHCPSOLICT (or DHCPDISCOVER) include more details,
such as the address binding information (since a DHCPOFFER includes
addresses). Also, this means that the DHCPv6 model would have to reserve
addresses for clients that might not even use that server - I think that was
one of the benefits of the DHCPv6 model. Perhaps this is not a significant
issue as the IPv6 address space is so vast that wasting some addresses isn't
a big deal.

Also, if you keep DHCPOFFER functionality, the "C" bit WILL BE REQUIRED in
the DHCPSOLICIT (DHCPDISCOVER) because if the server's going to allocate
addresses, it needs to know to discard any old ones before it does that.
And, there's also the question of whether "C" means discard all addresses
for this client or only for this address binding (for the client).

You can easily see that adopting the DHCPv4 semantics will cause many other
changes and impacts. Do we have time to review all of these and make sure
we're clean?

I personally would like to keep the DHCPSOLICIT and DHCPADVERTISE. Jim also
gives some good arguments for keeping the names IPv6ish (to match ND and
addrconf). But my personal view is if it doesn't quack like a duck, smell
like a duck, walk like a duck, it ain't a duck.

If you want to change the DHCPREPLY to a DHCPACK (and DHCPNACK), I have less
of an issue with that name change as the functionality is very similar
there.

I think we're already keeping DHCPRELEASE?

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Tuesday, October 24, 2000 12:21 AM
To: DHCPv6 discussion list
Cc: kkinnear@cisco.com; bound@zk3.dec.com
Subject: Re: Discussion: Names and semantics of messages



>>          If indeed the semantics are similar enough that we can
>>          make them essentially identical (or a clean extension),
>>          then we would be foolish indeed to make them needlessly
>>          different.
>>
>>They are not similar or even close semantically or their behavior.

>We need to consider the fundamental requirements of the client-server 
>message exchanges over and above their definition in the current DHCPv6 
>draft spec.  Certainly, there are differences between the semantics (and 
>names) of the DHCPv6 messages and the RFC2131 messages.  But, are those 
>differences inherent in the

Not sure if my mail trashed the last part of your sentence?  I will
respond to parts below as the last part of this could say different
things.

>>          Reusing the existing RFC2131 semantics (and thus the
>>          names) would yield enormous dividends across a wide swath
>>          of the industry, from tech support to sniffer vendors,
>>          from training to marketing -- to say nothing of making
>>          the implementation job much more straightforward.
>>
>>Not if the semantics are different and that will cause pain in fact if
>>they are different they should be different.  And they are not the same.
>
>Jim, we disagree about this point.  In an earlier message to this list 
>(Subject: Re: Design team teleconference, 8/31, Date: Thu, 14 Sep 2000), I 
>wrote:

>>For example, the DHCPv6 Solicit message now acts pretty much like the
>>DHCPv4 DHCPDISCOVER message (allowing for differences in the message
>>formats).  The Advertise message acts pretty much like a DHCPOFFER, except
>>the Advertise doesn't include any offered parameters.  is there a reason
>>for the difference or could we include parameters in the DHCPv6 message
and
>>call it a DHCPOFFER?

>I've walked through the other DHCPv6 messages and am prepared to defend 
>(although I haven't written down the details) the claim that we can reuse 
>the DISCOVER/OFFER/REQUEST/ACK messages in DHCPv6.

The solicit below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 1 |C|P|  reserved |  prefix-len |   solicit-ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+o

The "C" bit will be gone I believe from consensus (just use release).

The "P" bit says return me a list of prefixes.  

The prefix-len tells the server the relays bits in the prefix.  

The solicit ID permits the client to differentiate between servers using
a different solicit ID we permit per input on previous draft.

The Solicit message is Multicast.

The Solicit does not let a client suggest addresses as in DHCPDISCOVER.

If we look at a solicit vs a DHCPDISCOVER on a datascope or tcpdump they
look completely different and are not identifiable.

The purpose of it is as a DHCPDISCOVER with new features.  Solicit is
the terminology in ND and addrconf and the messages do not have the same
content and therefore I believe they should be different. 

Advertise:

     0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 2 |  reserved   |   solicit-ID    |  preference   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              extensions (variable number and length) ...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Provides solicit-id to the client.
Provides preference value to client.
But note it does permit extensions.
Again Advertise is used in ND and addrconf.

I don't see the added value at all of making them the same as DHCPv4?

>>          If we *can* reuse (and perhaps extend cleanly) the
>>          existing RFC2131 semantics (and thus the names) we *must*
>>          consider doing it!  I think the discussion should be
>>          centered on whether we *can* do this.
>>
>>I don't agree.  What we have designed will work as messages and within a
>>transaction based architecture which dhcpv6 is.  Also I would argue our
>>objective is to get a draft out and I think a bit more than it will feel
>>better is a reason to change the dhcpv6 messages.
>>
>>I would like to hear technical and architectural reasons why some other
>>message type than the ones we have will work better.
>
>For me, the question is not whether some other set of messages will work 
>better; rather, the question for me is whether we need to redesign the 
>DHCPv4 messages and exchanges.

I don't think so. DHCPv4 works with IPv4 fine and the messages are
appropriate.  DHCPv6 needs to work with IPv6 and the messages are
appropriate, and have continuity with ND and addrconf which is the
engineering  goal, so DHCPv6 interoperates efficiently with addrconf and
I could use Kim's argument for keeping them by saying operators will
become use to solicit and advertise with IPv6 and having them be discover
and offer is not congruent for IPv6 operators.  And at some point IPv4
will go away and in fact some customers will use IPv6 and DHCPv6 on
networks and not use DHCPv4 or other IPv4 thingees that will need DHCPv6
(e.g. 3GPP Mobile IPv6 networks).

Bernie also did not want to change them and may have other input too.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Wed Oct 25 14:40:28 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22338;
	Wed, 25 Oct 2000 14:40:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9PIbMb16624;
	Wed, 25 Oct 2000 14:37:22 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9PIbBb19446
	for <dhcp-v6@bucknell.edu>; Wed, 25 Oct 2000 14:37:12 -0400 (EDT)
Received: (qmail 1976 invoked from network); 25 Oct 2000 18:37:10 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 25 Oct 2000 18:37:10 -0000
From: "Richard Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion: client identifier 
Date: Wed, 25 Oct 2000 11:37:06 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNEELCCIAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <200010240324.XAA0000796664@anw.zk3.dec.com>
Importance: Normal
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From:  Jim Bound
> Sent: Monday, October 23, 2000 8:24 PM

*Snip!*

> ... when the host (or node) moves off a
> link in IPv6 it will have a new prefix, not the same prefix.
>
...Jim, I'll accept this assertion without challenge, but this seems to be
key to developing a unique identifier, so we'd better be really, really
ceertain that it is correct....


*Snip!*

> .... In DHCPv6 the client-identifier of DCHPv4 is:
>
>      Prefix + Link-Local address
>
> Link-Local is guranteed to be unique in IPv6 on a link.
> Prefix is guranteed to be unique in a site (or even the Internet).
>
...somewhere along the line I missed general acceptance of the idea that
Link-Local address is *the* principal component of the identifier.  I
believe that Ralph summarized the prior discussion as the client is
responsible for generating or using a unique value.  Again, I won't protest
this if it accomplishes what we need -- after all, our DHCPv4 experience
with using the MAC address has been less than wonderful.


*Snip!*

> If we state the following and can agree to it:
>
>  1) UUIDs cannot be duplicated by hosts on a link.
>  2) binding-ids for interfaces must be different on a node.
>
> Then we can do DAD on UUID+binding-ids in IPv6 to verify they are
> unique on a link for an interface.
>
...unfortunately, your point (1) is exactly what has generated all the
discussion.  I deeply believe it is quite difficult, if not impossible, to
assert that (1) is always true -- that's why I think that the draft MUST
specify the characteristics of a collision so that implementors are better
able to detect it, and SHOULD provide our best ideas of how to resolve it,
WITHOUT specifying the method.

...or do I completely miss your point?


--Barr Hibbs
  UltraDNS Corporation



From owner-dhcp-v6@bucknell.edu  Wed Oct 25 20:22:59 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08382;
	Wed, 25 Oct 2000 20:22:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9Q0Jub26728;
	Wed, 25 Oct 2000 20:19:56 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9Q0Jjb05091
	for <dhcp-v6@bucknell.edu>; Wed, 25 Oct 2000 20:19:46 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 5E0E34505; Wed, 25 Oct 2000 20:19:30 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 3CE19461C
	for <dhcp-v6@bucknell.edu>; Wed, 25 Oct 2000 20:19:30 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id UAA0000759250; Wed, 25 Oct 2000 20:19:18 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010260019.UAA0000759250@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-reply-to: Your message of "Wed, 25 Oct 2000 11:37:06 PDT."
             <JCELKJCFMDGAKJCIGGPNEELCCIAA.rbhibbs@ultraDNS.com> 
Date: Wed, 25 Oct 2000 20:19:17 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> ... when the host (or node) moves off a
>> link in IPv6 it will have a new prefix, not the same prefix.
>
>...Jim, I'll accept this assertion without challenge, but this seems to be
>key to developing a unique identifier, so we'd better be really, really
>ceertain that it is correct....

This is from RFC 2373 

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

A conversation is in research discussion to let a prefix span
multiple links but then DAD MUST be able to be done across multiple
links is the strategy, so we would have to develop that.  But yes we can
depend on my above statement and how IPv6 is being deployed today.


>> .... In DHCPv6 the client-identifier of DCHPv4 is:
>>
>>      Prefix + Link-Local address
>>
>> Link-Local is guranteed to be unique in IPv6 on a link.
>> Prefix is guranteed to be unique in a site (or even the Internet).
>>
>...somewhere along the line I missed general acceptance of the idea that
>Link-Local address is *the* principal component of the identifier.  I
>believe that Ralph summarized the prior discussion as the client is
>responsible for generating or using a unique value.  Again, I won't protest
>this if it accomplishes what we need -- after all, our DHCPv4 experience
>with using the MAC address has been less than wonderful.

I agree with you and Ralph.  That part of my mail was to state the
current IPv6 means today.  For DHCPv6 I am convinced from all that we
don't want to use a NIC address for the identifier, but the UUID. So I
think we are talking in dhcpv6 now:

Prefix + UUID 

Or at least that is what I am suggesting.

>> If we state the following and can agree to it:
>>
>>  1) UUIDs cannot be duplicated by hosts on a link.
>>  2) binding-ids for interfaces must be different on a node.
>>
>> Then we can do DAD on UUID+binding-ids in IPv6 to verify they are
>> unique on a link for an interface.
>
>...unfortunately, your point (1) is exactly what has generated all the
>discussion.  I deeply believe it is quite difficult, if not impossible, to
>assert that (1) is always true -- that's why I think that the draft MUST
>specify the characteristics of a collision so that implementors are better
>able to detect it, and SHOULD provide our best ideas of how to resolve it,
>WITHOUT specifying the method.

(1) is easy to make true if you make the UUID the link-local address in
the IPv6 DAD algroithm and send it on the link alone or with a prefix of
FE80 (link-local).  This will prevent UUIDs from colliding with other
UUIDs on the link.  Then we don't have the issue.  What I am proposing
is 99.9% accurate and will just work if use what we are doing right now
on all our IPv6 implementations today.

regards,
/jim
...or do I completely miss your point?


--Barr Hibbs
  UltraDNS Corporation



From owner-dhcp-v6@bucknell.edu  Thu Oct 26 16:22:25 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17447;
	Thu, 26 Oct 2000 16:22:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9QKIib11591;
	Thu, 26 Oct 2000 16:18:44 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9QKIYb06873
	for <dhcp-v6@bucknell.edu>; Thu, 26 Oct 2000 16:18:34 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA04343 for <dhcp-v6@bucknell.edu>; Thu, 26 Oct 2000 16:18:17 -0400 (EDT)
Message-Id: <4.3.1.2.20001026153950.00b95e90@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 26 Oct 2000 16:18:28 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-Reply-To: <200010240324.XAA0000796664@anw.zk3.dec.com>
References: <Your message of "Mon, 23 Oct 2000 14:18:45 EDT." <4.3.1.2.20001023104537.00b48b80@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Here's another long message on the client identifier issue.  The
executive summary is that it seems to me that including the
prefix in an IA is in conflict with some of the basic uses
of an IA that Ted listed in his initial message...

=====

Jim - after thinking about your proposal and scenarios, I may have come
across a point in which we differ in our thinking about the use of
an IA-identifier.  Here's what I think we need to use the IA-identifier
for:

1 Differentiating between IAs (either IAs from different clients
   or different interfaces on a multi-homed host) at any given
   point in time
2 Uniformly identifying an IA over time
3 Determining that two IAs are from the same client
4 Providing a way to have a single authentication
   key work with all of a client's identity associations

These uses are taken from or edits of the points from Ted's
original kickoff message.

Ted's original proposal for using UUID+binding-id for an IA
can be used for 1-4, based on the assumption we can find
a permanent, unique value for every client to use as the UUID.

Using prefix+UUID+binding-id and DAD
to detect and avoid collisions on a link gives us an
IA that is guaranteed to be unique.  But, I don't think the
prefix+UID+binding-id model - assuming that the UUID may
change when a client changes links - can be used for 2 or 3,
and it can only be used for 4 for singly-homed hosts.

One problem arises from the use of the prefix in the IA.
If the prefix is part of the IA, then the IA for an interface
changes over time, and the server can't match an interface
that moves to a new link with its previous IA on the old
link.  You correctly observed that this problem corrects
itself when the old IA expires, but Ted initially raised
the issue because Ted's experience with DHCPv4 is that
leaving old leases around like that is unacceptable.

Another problem comes from the UUID potentially changing
because of a collision when the client moves to a new
link.  In that case, we also lose the ability to track
an IA over time, as well as the ability to associate
multiple IAs with a single client.

I do like the idea of doing some kind of active error
detection.  Perhaps there is a way in which we can
develop and suggest heuristics that servers can
use to disambiguate and report duplicate UUIDs?

- Ralph

At 11:24 PM 10/23/00 -0400, Jim Bound wrote:

>Now the other part of Ted's good idea is that we trash using the
>link-local address (and other input cause its tied to a NIC).  The
>link-local address above is changed to the UUID + binding-ID, so now
>we have prefix+UUID+binding-id.
>
>If we state the following and can agree to it:
>
>  1) UUIDs cannot be duplicated by hosts on a link.
>  2) binding-ids for interfaces must be different on a node.
>
>Then we can do DAD on UUID+binding-ids in IPv6 to verify they are unique
>on a link for an interface.
>
>The UUID can still be used for security and the node can keep it if it
>roams in the site.  If its UUID as it roams collides on a link with
>another UUID, one of them must change, and the visiting node would have
>to change as IPv6 DAD is specified today.  Then this means the node
>needs to reset its security parameters.  So if the UUIDs do not collide
>there is no problem and with a good algorithm for UUIDs we can be pretty
>sure in a site in DHCPv6 the UUIDs won't collide across links.  But if
>they do we have a mechanism to cover it.
>
>Then Node B can move to Alink and work as in my above example.
>
>In the above we integrate Ted's IA and UUID model right into the IPv6
>architectural benefits and it will work in the present spec for DHCPv6.
>I think a good and expedient solution for us.





From owner-dhcp-v6@bucknell.edu  Thu Oct 26 23:01:04 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18770;
	Thu, 26 Oct 2000 23:01:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9R2wBb31029;
	Thu, 26 Oct 2000 22:58:11 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9R2w1b04532
	for <dhcp-v6@bucknell.edu>; Thu, 26 Oct 2000 22:58:01 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 12F182DC2; Thu, 26 Oct 2000 21:57:45 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 850732D8F
	for <dhcp-v6@bucknell.edu>; Thu, 26 Oct 2000 21:57:44 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000639026; Thu, 26 Oct 2000 22:57:19 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200010270257.WAA0000639026@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion: client identifier 
In-reply-to: Your message of "Thu, 26 Oct 2000 16:18:28 EDT."
             <4.3.1.2.20001026153950.00b95e90@mail.bucknell.edu> 
Date: Thu, 26 Oct 2000 22:57:17 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Ralph,

>Jim - after thinking about your proposal and scenarios, I may have come
>across a point in which we differ in our thinking about the use of
>an IA-identifier.  Here's what I think we need to use the IA-identifier
>for:

>1 Differentiating between IAs (either IAs from different clients
>   or different interfaces on a multi-homed host) at any given
>   point in time
>2 Uniformly identifying an IA over time
>3 Determining that two IAs are from the same client
>4 Providing a way to have a single authentication
>   key work with all of a client's identity associations

>These uses are taken from or edits of the points from Ted's
>original kickoff message.

>Ted's original proposal for using UUID+binding-id for an IA
>can be used for 1-4, based on the assumption we can find
>a permanent, unique value for every client to use as the UUID.

As a note I am challenging that assumption that we can build a UUID that
is unique for every client and I don't think we or anyone can gurantee
it.  Thats why I made my proposal.

>Using prefix+UUID+binding-id and DAD
>to detect and avoid collisions on a link gives us an
>IA that is guaranteed to be unique.  But, I don't think the
>prefix+UID+binding-id model - assuming that the UUID may
>change when a client changes links - can be used for 2 or 3,
>and it can only be used for 4 for singly-homed hosts.

I believe that it can work for 3 as long as the client can keep its UUID
while moving from one link to another as I outlined in my previous mail.
Once their is a collision on the link then the UUID has to change yes.

I think it would work for 4 two.  The UUID would be the same for both
interfaces but the prefixes would be different if multihomed on two
links.  On one link the binding-id would differentiate the IAs.

The server and client use the UUID for uniformity and security in the
model I proposed and 1-4 works as long as the UUID don't change.

If the UUID collides on the link then yes all bets are off.

But I would propose to the WG that the way I am trying to use Ted's
model will in fact work with a UUID algorithm that is mostly going to
work.  And if it does not then the client must get another UUID.

Also a sub proposal I am making is that no matter what model we use for
this DAD should be performed on the UUID+binding-id in DHCPv6 anyway.  I
don't believe we should permit duplicate UUIDs on two different nodes.

>One problem arises from the use of the prefix in the IA.
>If the prefix is part of the IA, then the IA for an interface
>changes over time, and the server can't match an interface
>that moves to a new link with its previous IA on the old
>link.  You correctly observed that this problem corrects
>itself when the old IA expires, but Ted initially raised
>the issue because Ted's experience with DHCPv4 is that
>leaving old leases around like that is unacceptable.

But if the UUID is maintained across prefix changes that can be tracked
pretty easily by the server and can react to that mobile situation.  

Clearly it is a trade-off discussion.

>Another problem comes from the UUID potentially changing
>because of a collision when the client moves to a new
>link.  In that case, we also lose the ability to track
>an IA over time, as well as the ability to associate
>multiple IAs with a single client.

Yes that can happen.    

>I do like the idea of doing some kind of active error
>detection.  Perhaps there is a way in which we can
>develop and suggest heuristics that servers can
>use to disambiguate and report duplicate UUIDs?

I think what I will do is lay out what I see are all the holes with not
using a prefix and the drawbacks and then we can compare the list and
see where this is then too.  I will do this next week.
Then the trade-off discussion has an equal weight for analysis.  

/jim