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-v4@bucknell.edu  Thu Oct  5 14:11:39 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 OAA04213
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 5 Oct 2000 14:11:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e95Hxwb31756;
	Thu, 5 Oct 2000 13:59:58 -0400 (EDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e95Hxhb07483
	for <dhcp-v4@bucknell.edu>; Thu, 5 Oct 2000 13:59:43 -0400 (EDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Oct 2000 10:59:27 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <4HBHZ2QF>; Thu, 5 Oct 2000 10:59:25 -0700
Message-ID: <5F1EEFAFB3573A46812FE84EF29C9AF5010D92B3@red-msg-05.redmond.corp.microsoft.com>
From: Matthew Williamson <mattwi@microsoft.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: CSR Draft
Date: Thu, 5 Oct 2000 09:39:49 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Reply-To: mattwi@microsoft.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hello All,

Could I get an update on the state of the Classless source routing draft?
Has it gone last call yet?  I don't see anything in my archives stating so,
and would appreciate an update.

Thank you,

Matthew



From owner-dhcp-v4@bucknell.edu  Thu Oct  5 16:28:28 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 QAA06401
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 5 Oct 2000 16:28:27 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e95KOfb09463;
	Thu, 5 Oct 2000 16:24:41 -0400 (EDT)
Received: from elbarto.treck.com ([208.229.201.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e95KOdb11209
	for <dhcp-v4@bucknell.edu>; Thu, 5 Oct 2000 16:24:39 -0400 (EDT)
Received: by ELBARTO with Internet Mail Service (5.5.2650.21)
	id <4K3CSZRA>; Thu, 5 Oct 2000 16:24:36 -0400
Message-ID: <F0A2319CE498D411928600A0CC581BEE2824@ELBARTO>
From: Jared August <jaugust@treck.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Status of Autoconfig Draft
Date: Thu, 5 Oct 2000 16:24:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: jaugust@treck.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hello,

I've been asked to research AutoIP (draft-ietf-dhc-ipv4-autoconfig-05), and
was wondering what the status of the draft is. I notice that it has expired
- is there any ongoing work on it? I looked through the archive but didn't
notice anything. Any information would be greatly appreciated.

Thank you,
Jared



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-v4@bucknell.edu  Fri Oct  6 16:41: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 QAA12463
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 6 Oct 2000 16:41:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e96Kadb13628;
	Fri, 6 Oct 2000 16:36:39 -0400 (EDT)
Received: from firewall.agranat.com (agranat.com [198.113.147.2])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e96KaSb22652
	for <dhcp-v4@bucknell.edu>; Fri, 6 Oct 2000 16:36:28 -0400 (EDT)
Received: from agranat.com (alice.agranat.com [192.104.71.130])
	by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id QAA11535
	for <dhcp-v4@bucknell.edu>; Fri, 6 Oct 2000 16:36:11 -0400
Received: (from worley@localhost)
	by agranat.com (8.8.5/8.8.5) id QAA05132;
	Fri, 6 Oct 2000 16:36:10 -0400
Date: Fri, 6 Oct 2000 16:36:10 -0400
Message-Id: <200010062036.QAA05132@agranat.com>
X-Authentication-Warning: alice.agranat.com: worley set sender to worley@alice.agranat.com using -f
From: Dale Worley <worley@agranat.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
In-reply-to: <F0A2319CE498D411928600A0CC581BEE2824@ELBARTO> (message from
	Jared August on Thu, 5 Oct 2000 16:24:27 -0400)
Subject: Re: Status of Autoconfig Draft
References:  <F0A2319CE498D411928600A0CC581BEE2824@ELBARTO>
Reply-To: worley@agranat.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

   From: Jared August <jaugust@treck.com>

   I've been asked to research AutoIP
   (draft-ietf-dhc-ipv4-autoconfig-05), and was wondering what the
   status of the draft is. I notice that it has expired - is there any
   ongoing work on it? I looked through the archive but didn't notice
   anything. Any information would be greatly appreciated.

AutoIP has never been widely accepted, I think, but people are
starting to use it.  E.g., the Universal Plug and Play protocol uses
it.  I expect usage to increase over time.  So it would probably be
useful to revise the Internet Draft for AutoIP, and hopefully get a
carefully-examined version of it turned into an RFC.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <dworley@virata.com>
Virata Corp.	  Applications Infrastructure   http://emweb.com



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-v4@bucknell.edu  Fri Oct  6 23:10: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 XAA18705
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 6 Oct 2000 23:10:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9736Db21936;
	Fri, 6 Oct 2000 23:06:13 -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 e97366b10040
	for <dhcp-v4@bucknell.edu>; Fri, 6 Oct 2000 23:06:07 -0400 (EDT)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA10508;
	Fri, 6 Oct 2000 20:06:04 -0700 (PDT)
Received: from vayne (muc-isdn-20 [129.157.164.120])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id FAA14575;
	Sat, 7 Oct 2000 05:03:38 +0200 (MET DST)
Date: Sat, 7 Oct 2000 05:13:11 +0200 (MET DST)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: Re: Status of Autoconfig Draft
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
In-Reply-To: "Your message with ID" <200010062036.QAA05132@agranat.com>
Message-ID: <Roam.SIMC.2.0.6.970888391.4774.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>    From: Jared August <jaugust@treck.com>
> 
>    I've been asked to research AutoIP
>    (draft-ietf-dhc-ipv4-autoconfig-05), and was wondering what the
>    status of the draft is. I notice that it has expired - is there any
>    ongoing work on it? I looked through the archive but didn't notice
>    anything. Any information would be greatly appreciated.
> 
> AutoIP has never been widely accepted, I think, but people are
> starting to use it.  E.g., the Universal Plug and Play protocol uses
> it.  I expect usage to increase over time.  So it would probably be
> useful to revise the Internet Draft for AutoIP, and hopefully get a
> carefully-examined version of it turned into an RFC.

The ZEROCONF WG has been chartered to work on this issue and produce
a standards track RFC on auto configuration for IPv4.  The following
is a quote from the ZEROCONF WG charter:

   The WG will also produce protocol specifications for Automatic Address 
   Configuration for IPv4 and a Multicast Address Allocation Protocol for
   IPv4 and IPv6. 

   Goals and Milestones:

   Oct 00   
        Submit internet-draft to be considered as an Informational RFC on 
        Requirements for Zero Configuration Networking.
   Dec 00
        
        Submit Automatic Address Configuration for IPv4 to be considered as a 
        Standards Track RFC.

The DHC WG decided in Adelaide (IETF 47) that auto configuration for
IPv4 was NOT within the scope of the WG.  From the IETF 47 minutes:

   Dynamic Configuration of IPv4 Link-local Addresses

   Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network

   Stuart Cheshire, Ralph Droms

   ----------------------------

   The WG suggested that Cheshire submit his draft as an independent
   submission for review by zeroconf and dhc WGs.

So, the work items ahead of us are:

1) Publishing a draft-ietf-zeroconf-ipv4-autoconf-00.txt draft

2) Discontinuing the draft-dhc-ipv4-autoconf-05.txt draft

3) Getting all parties interested in seeing this standard moving
   forward participating in the ZEROCONF WG effort to specify this.

Erik Guttman
ZEROCONF WG Cochair



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-v4@bucknell.edu  Sun Oct  8 01:43: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 BAA17215
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 8 Oct 2000 01:43:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e985dFb15485;
	Sun, 8 Oct 2000 01:39:15 -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 e985dEb29476
	for <dhcp-v4@bucknell.edu>; Sun, 8 Oct 2000 01:39:14 -0400 (EDT)
Received: from internaut.com (uucp@localhost)
	by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id WAA29520;
	Sat, 7 Oct 2000 22:39:07 -0700 (PDT)
Received: from [204.57.137.69] by internaut.com (NX5.67e/NeXT-3.0)
	id AA07375; Sat, 7 Oct 00 21:55:17 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Status of Autoconfig Draft
Date: Sat, 7 Oct 2000 22:13:14 -0700
Message-Id: <OJEJKOMOEAKLMOILFCPJMEMLDGAA.aboba@internaut.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.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.970888391.4774.erikg@sun-ffm.germany>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: aboba@internaut.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

>Discontinuing the draft-dhc-ipv4-autoconf-05.txt draft

While I certainly agree with the idea of going ahead with
standardizing auto-configuration, I also believe that it is
important to document existing practice in an informational
RFC. Today there are tens of millions of hosts which 
behave something along the lines described in 
draft-dhc-ipv4-autoconf-05.txt and so it is valuable to
have this behavior documented somewhere. As a result, I 
do not believe that it makes sense to let
draft-dhc-ipv4-autoconf-05.txt expire completely. Rather,
the draft should focus solely on behavior that is already
implemented. 



From owner-dhcp-v4@bucknell.edu  Sun Oct  8 08:46: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 IAA08818
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 8 Oct 2000 08:46:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e98CgOb23210;
	Sun, 8 Oct 2000 08:42:24 -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 e98Cg8b13696
	for <dhcp-v4@bucknell.edu>; Sun, 8 Oct 2000 08:42:08 -0400 (EDT)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14000;
	Sun, 8 Oct 2000 05:42:05 -0700 (PDT)
Received: from vayne (muc-isdn-17 [129.157.164.117])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id OAA04324;
	Sun, 8 Oct 2000 14:42:02 +0200 (MET DST)
Date: Sun, 8 Oct 2000 14:51:45 +0200 (MET DST)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: RE: Status of Autoconfig Draft
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: Erik Guttman <Erik.Guttman@germany.sun.com>,
        DHCPv4 discussion list <dhcp-v4@bucknell.edu>, cheshire@apple.com,
        erik.guttman@germany.sun.com
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJMEMLDGAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.971009505.14465.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> >Discontinuing the draft-dhc-ipv4-autoconf-05.txt draft
> 
> While I certainly agree with the idea of going ahead with
> standardizing auto-configuration, I also believe that it is
> important to document existing practice in an informational
> RFC. Today there are tens of millions of hosts which 
> behave something along the lines described in 
> draft-dhc-ipv4-autoconf-05.txt and so it is valuable to
> have this behavior documented somewhere. As a result, I 
> do not believe that it makes sense to let
> draft-dhc-ipv4-autoconf-05.txt expire completely. Rather,
> the draft should focus solely on behavior that is already
> implemented. 

Bernard,

I believe that the zeroconf document must also focus on
documenting the way that hosts are implemented.

We also want to consider issues which were not in the DHC
draft:  Multi-homing and assignment of both link-local and
global scope addresses to a single interface.

The document may define new protocol, but it has to be 
backwardly compatible with the installed base.  At least
IMO.

Perhaps, if we can't come to a quick concensus about 
the combined standard definition and legacy non-standard
description, we should have two parallel drafts (standards
track and informational, respectively) that proceed 
independently.  I think that's a bad idea, as some folks 
will get confused and implement the legacy version where 
we'd really like them to implement the standard one in the 
future.

Erik



From owner-dhcp-v4@bucknell.edu  Sun Oct  8 16:12: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 QAA11133
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 8 Oct 2000 16:12:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e98K8Zb11260;
	Sun, 8 Oct 2000 16:08:35 -0400 (EDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e98K8Sb31569
	for <dhcp-v4@bucknell.edu>; Sun, 8 Oct 2000 16:08:28 -0400 (EDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA26331
	for <dhcp-v4@bucknell.edu>; Sun, 8 Oct 2000 13:08:24 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e11874f212538cc@mailgate1.apple.com>;
 Sun, 8 Oct 2000 13:08:23 -0700
Received: from [206.111.147.153] (vpn-pp-27.apple.com [17.254.144.26])
	by scv1.apple.com (8.9.3/8.9.3) with ESMTP id NAA27713;
	Sun, 8 Oct 2000 13:08:23 -0700 (PDT)
User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630)
Date: Sun, 08 Oct 2000 13:09:37 -0700
Subject: Re: Status of Autoconfig Draft
From: Stuart Cheshire <cheshire@apple.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Message-ID: <B6062291.5675%cheshire@apple.com>
In-Reply-To: <F0A2319CE498D411928600A0CC581BEE2824@ELBARTO>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Reply-To: cheshire@apple.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

> I've been asked to research AutoIP

In fact that is exactly what I've been working on this week. Erik Guttman
has been reminding me for some time to get a new draft submitted now that it
is an official work item on the Zeroconf charter.

I finished incorporating the last round of suggestions this morning, and
posted the draft with its new official draft-ietf-zeroconf filename today.

For eager people who can't wait for it to appear in the Internet Drafts
directory, you can get it right away at:
<http://web.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal-00.txt>

I'm hoping that we can get agreement on this and wrap it up rapidly.
Both Mac OS and Microsoft Windows have implemented 169.254/16 link-local
addresses for several years now, and every day we continue to debate the
finer points of this document is taking time away from the far more
important matter of getting IPv6 deployed.

Please send any comments to the zeroconf mailing list or to me directly and
we can hopefully finish this off and put it behind us.

Stuart Cheshire <cheshire@apple.com>



From owner-dhcp-v4@bucknell.edu  Sun Oct  8 17:02: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 RAA11351
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 8 Oct 2000 17:02:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e98KxIb23749;
	Sun, 8 Oct 2000 16:59:18 -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 e98KxCb21470
	for <dhcp-v4@bucknell.edu>; Sun, 8 Oct 2000 16:59:12 -0400 (EDT)
Received: from internaut.com (uucp@localhost)
	by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id NAA27768;
	Sun, 8 Oct 2000 13:59:10 -0700 (PDT)
Received: from [204.57.137.69] by internaut.com (NX5.67e/NeXT-3.0)
	id AA03663; Sun, 8 Oct 00 13:03:08 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: "DHCPv4 discussion list" <dhcp-v4@bucknell.edu>, <cheshire@apple.com>
Subject: RE: Status of Autoconfig Draft
Date: Sun, 8 Oct 2000 13:21:06 -0700
Message-Id: <OJEJKOMOEAKLMOILFCPJGEMPDGAA.aboba@internaut.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.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.971009505.14465.erikg@sun-ffm.germany>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: aboba@internaut.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

>We should have two parallel drafts (standards
>track and informational, respectively) that proceed 
>independently.  I think that's a bad idea, as some folks 
>will get confused and implement the legacy version where 
>we'd really like them to implement the standard one in the 
>future.

The confusion arises from the fact that 
draft-dhc-ipv4-autoconf-05.txt today combines description
of existing practice along with recommendations on future
implementations. I would recommend that all portions
of the draft referring to non-implemented functionality
(such as the DHCP option for control of auto-config 
behavior) be removed, and that the draft state clearly that it
is not a standards track document. The new draft would
focus solely on documenting the functionality shipped
in MacOS and Windows. It is also ok if this draft were
to point out various weaknesses of the legacy approach. 

We could then move forward with a separate standards
track document. 



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-v4@bucknell.edu  Mon Oct  9 11:06: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 LAA05311
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 9 Oct 2000 11:06:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e99F3Ub02186;
	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: DHCPv4 discussion list <dhcp-v4@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: rdroms@cisco.com
Sender: owner-dhcp-v4@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-v4@bucknell.edu  Wed Oct 11 18:13: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 SAA22876
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 11 Oct 2000 18:13:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9BM9Hb02905;
	Wed, 11 Oct 2000 18:09:17 -0400 (EDT)
Received: from quadntweb.quadritek.com ([198.200.138.211])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9BM9Bb21852
	for <dhcp-v4@bucknell.edu>; Wed, 11 Oct 2000 18:09:11 -0400 (EDT)
Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35)
          with SMTP id com for <dhcp-v4@bucknell.edu>;
          Wed, 11 Oct 2000 17:59:39 -0400
From: "A. Gregory Rabil" <grabil@lucent.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed Standard
Date: Wed, 11 Oct 2000 18:09:14 -0400
Message-ID: <01be01c033cf$e482ad30$fe8ac8c6@quadritek.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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200010101815.OAA09571@ietf.org>
Reply-To: grabil@lucent.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.



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-v4@bucknell.edu  Thu Oct 12 09:24:17 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 JAA25055
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 12 Oct 2000 09:24:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9CDJvb00271;
	Thu, 12 Oct 2000 09:19:58 -0400 (EDT)
Received: from ormail2.orckit.com ([194.90.167.36])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9CDJEb29411
	for <dhcp-v4@bucknell.edu>; Thu, 12 Oct 2000 09:19:16 -0400 (EDT)
Received: by ORMAIL2 with Internet Mail Service (5.5.2650.21)
	id <4PJBFM25>; Thu, 12 Oct 2000 15:18:06 +0200
Message-ID: <B059514836CAD3119FEC0008C78670AB112EFA@ORMAIL1>
From: Ofer Dayan <Oferd@orckit.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: DHCP MIBs
Date: Thu, 12 Oct 2000 15:18:05 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-8"
Reply-To: Oferd@orckit.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi, 

Could anyone please direct me to MIBs referring to DHCP ?


thanks, 

	Ofer



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-v4@bucknell.edu  Fri Oct 13 10:33:11 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 KAA06707
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 13 Oct 2000 10:33:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DESCb19384;
	Fri, 13 Oct 2000 10:28:12 -0400 (EDT)
Received: from motgate3.mot.com ([144.189.100.103])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9DERub11458
	for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 10:27:56 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA09252 for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 07:25:15 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA14767 for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 07:27:52 -0700 (MST)]
Received: from dma.isg.mot.com (cabs2.dma.isg.mot.com [150.21.2.48])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA24018
	for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 10:27:51 -0400 (EDT)
Message-Id: <200010131427.KAA24018@noah.dma.isg.mot.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: dhcp agent options draft 12
Date: Fri, 13 Oct 2000 10:27:51 -0400
From: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
Reply-To: mpatrick@dma.isg.mot.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN







INTERNET DRAFT


DHC  Working Grop                                      Michael Patrick
<draft-ietf-dhc-agent-options-12.txt>                  Motorola BCS
                                                       October 11, 2000


                  DHCP Relay Agent Information Option

Status of this Memo


   This document is an Internet Draft and is in full conformance of
   section 10 of RFC2026.  Internet Drafts are working documents of the
   Internet Engineering Task Force (IETF), its Areas, and its Working
   Groups.  Note that other groups may also distribute working documents
   as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shado Directories can be accessed at
   http://ww.ietf.org/shadow.html


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

Abstract

   Newer high-speed public Internet access technologies call for a
   high-speed modem to have a LAN attachment to one or more customer
   premise hosts.  It is advantageous to use the Dynamic Host
   Configuration Protocol as defined in RFC 2131 [1] to assign customer
   premise host IP addresses in this environment. However, a number of
   security and scaling problems arise with such "public" DHCP use.
   This document describes a new DHCP option to address these issues.
   This option extends the set of DHCP options as defined in RFC 2132
   [2].




Expires April 2001                                              [Page 1]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   The new option is called the Relay Agent Information option and is
   inserted by the DHCP relay agent when forwarding client-originated
   DHCP packets to a DHCP server.  Servers recognizing the Relay Agent
   Information option may use the information to implement IP address or
   other parameter assignment policies. The DHCP Server echoes the
   option back verbatim to the relay agent in server-to-client replies,
   and the relay agent strips the option before forwarding the reply to
   the client.

   The "Relay Agent Information" option is organized as a single DHCP
   option that contains one or more "sub-options" that convey
   information known by the relay agent.  The initial sub-options are
   defined for a relay agent that is co-located in a public circuit
   access unit.  These include a "circuit ID" for the incoming circuit,
   and a "remote ID" which provides a trusted identifier for the remote
   high-speed modem.

Table of Contents

        1   Introduction........................................... 2
        1.1 High-Speed Circuit Switched Data Networks.............. 2
        1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4
        2.0 Relay Agent Information Option......................... 5
        2.1 Agent Operation........................................ 6
        2.1.1 Reforwarded DHCP requests............................ 7
        2.2 Server Operation....................................... 7
        3.0 Relay Agent Information Suboptions..................... 8
        3.1 Agent Circuit ID....................................... 8
        3.2 Agent Remote ID........................................ 9
        4.0 Issues Resolved........................................ 10
        5.0 Security Considerations................................ 11
        6.0 IANA Considerations.................................... 11
        7.0 Intellectual Property Notice........................... 12
        8.0 References............................................. 12
        9.0 Glossary............................................... 13
        10.0 Author's Address...................................... 13



1   Introduction

1.1 High-Speed Circuit Switched Data Networks

   Public Access to the Internet is usually via a circuit switched data
   network.  Today, this is primarily implemented with dial-up modems
   connecting to a Remote Access Server.  But higher speed circuit
   access networks also include ISDN, ATM, Frame Relay, and Cable Data
   Networks.  All of these networks can be characterized as a "star"



Expires April 2001                                              [Page 2]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   topology where multiple users connect to a "circuit access unit" via
   switched or permanent circuits.

   With dial-up modems, only a single host PC attempts to connect to the
   central point.  The PPP protocol is widely used to assign IP
   addresses to be used by the single host PC.

   The newer high-speed circuit technologies, however, frequently
   provide a LAN interface (especially Ethernet) to one or more host
   PCs.  It is desirable to support centralized assignment of the IP
   addresses of host computers connecting on such circuits via DHCP.
   The DHCP server can be, but usually is not, co-implemented with the
   centralized circuit concentration access device.  The DHCP server is
   often connected as a separate server on the "Central LAN" to which
   the central access device (or devices) attach.

   A common physical model for high-speed Internet circuit access is
   shown in Figure 1, below.




                      +---------------+                          |
        Central       |   Circuit     |-- ckt 1--- Modem1-- Host-|- Host A
        LAN     |     |   Access      |                     Lan  |- Host B
                |     |   Unit 1      |                          |- Host C
                |-----|               |--                        |
                |     |(relay agent)  |...
   +---------+  |     +---------------+
   |  DHCP   |--|
   | Server  |  |
   +---------+  |
                |
                |     +---------------+
   +---------+  |     |   Circuit     |-- ckt 1--- Modem2-- Host--- Host D
   | Other   |  |     |   Access      |                     Lan
   | Servers |--|-----|   Unit 2      |
   |  (Web,  |  |     |               |-- ckt 2--- Modem3-- Host--- Host E
   |   DNS)  |  |     |(relay agent)  |...                  Lan
   |         |        +---------------+
   +---------+
            Figure 1:  DHCP High Speed Circuit Access Model


   Note that in this model, the "modem" connects to a LAN at the user
   site, rather than to a single host. Multiple hosts are implemented at
   this site.  Although it is certainly possible to implement a full IP
   router at the user site, this requires a relatively expensive piece



Expires April 2001                                              [Page 3]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   of equipment (compared to typical modem costs).  Furthermore, a
   router requires an IP address not only for every host, but for the
   router itself. Finally, a user-side router requires a dedicated
   Logical IP Subnet (LIS) for each user.  While this model is
   appropriate for relatively small corporate networking environments,
   it is not appropriate for large, public accessed networks. In this
   scenario, it is advantageous to implement an IP networking model that
   does not allocate an IP address for the modem (or other networking
   equipment device at the user site), and especially not an entire LIS
   for the user side LAN.

   Note that using this method to obtain IP addresses means that IP
   addresses can only be obtained while communication to the central
   site is available. Some host lan installations may use a local DHCP
   server or other methods to obtain IP addresses for in-house use.

1.2 DHCP Relay Agent in the Circuit Access Unit

   It is desirable to use DHCP to assign the IP addresses for public
   high-speed circuit access.  A number of circuit access units (e.g.
   RAS's, cable modem termination systems, ADSL access units, etc)
   connect to a LAN (or local internet) to which is attached a DHCP
   server.

   For scaling and security reasons, it is advantageous to implement a
   "router hop" at the circuit access unit, much like high-capacity
   RAS's do today.  The circuit access equipment acts as both a router
   to the circuits and as the DHCP relay agent.

   The advantages of co-locating the DHCP relay agent with the circuit
   access equipment are:

   DHCP broadcast replies can be routed to only the proper circuit,
   avoiding, say, the replication of the DCHP reply broadcast onto
   thousands of access circuits;

   The same mechanism used to identify the remote connection of the
   circuit (e.g. a user ID requested by a Remote Access Server acting as
   the circuit access equipment) may be used as a host identifier by
   DHCP, and used for parameter assignment.  This includes centralized
   assignment of IP addresses to hosts.  This provides a secure remote
   ID from a trusted source -- the relay agent.

   A number of issues arise when forwarding DHCP requests from hosts
   connecting publicly accessed high-speed circuits with LAN connections
   at the host. Many of these are security issues arising from DHCP
   client requests from untrusted sources.  How does the relay agent
   know to which circuit to forward replies?  How does the system



Expires April 2001                                              [Page 4]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   prevent  DHCP IP exhaustion attacks?  This is when an attacker
   requests all available IP addresses from a DHCP server by sending
   requests with fabricated client MAC addresses.  How can an IP address
   or LIS be permanently assigned to a particular user or modem?  How
   does one prevent "spoofing" of client identifer fields used to assign
   IP addresses?  How does one prevent denial of service by "spoofing"
   other client's MAC addresses?

   All of these issues may be addressed by having the circuit access
   equipment, which is a trusted component, add information to DHCP
   client requests that it forwards to the DHCP server.

2.0 Relay Agent Information Option

   This document defines a new DHCP Option called the Relay Agent
   Information Option.  It is a "container" option for specific agent-
   supplied sub-options.  The format of the Relay Agent Information
   option is:


            Code   Len     Agent Information Field
           +------+------+------+------+------+------+--...-+------+
           |  82  |   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |
           +------+------+------+------+------+------+--...-+------+

   The length N gives the total number of octets in the Agent
   Information Field. The Agent Information field consists of a sequence
   of SubOpt/Length/Value tuples for each sub-option, encoded in the
   following manner:


            SubOpt  Len     Sub-option Value
           +------+------+------+------+------+------+--...-+------+
           |  1   |   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |
           +------+------+------+------+------+------+--...-+------+
            SubOpt  Len     Sub-option Value
           +------+------+------+------+------+------+--...-+------+
           |  2   |   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |
           +------+------+------+------+------+------+--...-+------+


   No "pad" sub-option is defined, and the Information field shall NOT
   be terminated with a 255 sub-option.  The length N of the DHCP Agent
   Information Option shall include all bytes of the sub-option
   code/length/value tuples. Since at least one sub-option must be
   defined, the minimum Relay Agent Information length is two (2).  The
   length N of the sub-options shall be the number of octets in only
   that sub-option's value field.  A sub-option length may be zero.  The



Expires April 2001                                              [Page 5]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   sub-options need not appear in sub-option code order.


   The initial assignment of DHCP Relay Agent Sub-options is as follows:


                   DHCP Agent              Sub-Option Descrption
                   Sub-option Code
                   ---------------         ----------------------
                       1                   Agent Circuit ID Sub-option
                       2                   Agent Remote ID Sub-option



2.1 Agent Operation

   Overall adding of the DHCP relay agent option SHOULD be configurable,
   and SHOULD be disabled by default. Relay agents SHOULD have separate
   configurables for each sub-option to control whether it is added to
   client-to-server packets.

   A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last option (but before 'End Option' 255, if present) in
   the DHCP options field of any recognized BOOTP or DHCP packet
   forwarded from a client to a server.

   Relay agents receiving a DHCP packet from an untrusted circuit with
   giaddr set to zero (indicating that they are the first-hop router)
   but with a Relay Agent Information option already present in the
   packet SHALL discard the packet and increment an error count.  A
   trusted circuit may contain a trusted downstream (closer to client)
   network element (bridge) between the relay agent and the client that
   MAY add a relay agent option but not set the giaddr field.  In this
   case, the relay agent does NOT add a "second" relay agent option, but
   forwards the DHCP packet per normal DHCP relay agent operations,
   setting the giaddr field as it deems appropriate.

   The mechanisms for distinguishing between "trusted" and "untrusted"
   circuits are specific to the type of circuit termination equipment,
   and may involve local administration. For example, a Cable Modem
   Termination System may consider upstream packets from most cable
   modems as "untrusted", but an ATM switch terminating VCs switched
   through a DSLAM may consider such VCs as "trusted" and accept a relay
   agent option added by the DSLAM.

   Relay agents MAY have a configurable for the maximum size of the DHCP
   packet to be created after appending the Agent Information option.
   Packets which, after appending the Relay Agent Information option,



Expires April 2001                                              [Page 6]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   would exceed this configured maximum size shall be forwarded WITHOUT
   adding the Agent Information option. An error counter SHOULD be
   incremented in this case.  In the absence of this configurable, the
   agent SHALL NOT increase a forwarded DHCP packet size to exceed the
   MTU of the interface on which it is forwarded.

   The Relay Agent Information option echoed by a server MUST be removed
   by either the relay agent or the trusted downstream network element
   which added it when forwarding a server-to-client response back to
   the client.

   The agent SHALL NOT add an "Option Overload" option to the packet or
   use the "file" or "sname" fields for adding Relay Agent Information
   option.  It SHALL NOT parse or remove Relay Agent Information options
   that may appear in the sname or file fields of a server-to-client
   packet forwarded through the agent.

   The operation of relay agents for specific sub-options is specified
   with that sub-option.

   Relay agents are NOT required to monitor or modify client-originated
   DHCP packets addressed to a server unicast address. This  includes
   the DHCP-REQUEST sent when entering the RENEWING state.

   Relay agents MUST NOT modify DHCP packets that use the IPSEC
   Authentication Header or IPSEC Encapsulating Security Payload [6].

2.1.1 Reforwarded DHCP requests

   A DHCP relay agent may receive a client DHCP packet forwarded from a
   BOOTP/DHCP relay agent closer to the client. Such a packet will have
   giaddr as non-zero, and may or may not already have a DHCP Relay
   Agent option in it.

   Relay agents configured to add a Relay Agent option which receive a
   client DHCP packet with a nonzero giaddr SHALL discard the packet if
   the giaddr spoofs a giaddr address implemented by the local agent
   itself.

   Otherwise, the relay agent SHALL forward any received DHCP packet
   with a valid non-zero giaddr WITHOUT adding any relay agent options.
   Per RFC 2131, it shall also NOT modify the giaddr value.


2.2     Server Operation

   DHCP servers unaware of the Relay Agent Information option will
   ignore the option upon receive and will not echo it back on



Expires April 2001                                              [Page 7]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   responses.  This is the specified server behavior for unknown
   options.

   DHCP servers claiming to support the Relay Agent Information option
   SHALL echo the entire contents of the Relay Agent Information option
   in all replies.  Servers SHOULD copy the Relay Agent Information
   option as the last DHCP option in the response.  Servers SHALL NOT
   place the echoed Relay Agent Information option in the overloaded
   sname or file fields.  If a server is unable to copy a full Relay
   Agent Information field into a response, it SHALL send the response
   without the Relay Information Field, and SHOULD increment an error
   counter for the situation.

   The operation of DHCP servers for specific sub-options is specified
   with that sub-option.

   Note that DHCP relay agents are not required to monitor unicast DHCP
   messages sent directly between the client and server (i.e, those that
   aren't sent via a relay agent). However, some relay agents MAY chose
   to do such monitoring and add relay agent options. Consequently,
   servers SHOULD be prepared to handle relay agent options in unicast
   messages, but MUST NOT expect them to always be there.





























Expires April 2001                                              [Page 8]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


3.0 Relay Agent Information Sub-options

3.1 Agent Circuit ID Sub-option

   This sub-option MAY be added by DHCP relay agents which terminate
   switched or permanent circuits.  It encodes an agent-local identifier
   of the circuit from which a DHCP client-to-server packet was
   received.  It is intended for use by agents in relaying DHCP
   responses back to the proper circuit.  Possible uses of this field
   include
       - Router interface number
       - Switching Hub port number
       - Remote Access Server port number
       - Frame Relay DLCI
       - ATM virtual circuit number
       - Cable Data virtual circuit number

   Servers MAY use the Circuit ID for IP and other parameter assignment
   policies. The Circuit ID SHOULD be considered an opaque value, with
   policies based on exact string match only; that is, the Circuit ID
   SHOULD NOT be internally parsed by the server.

   The DHCP server SHOULD report the Agent Circuit ID value of current
   leases in statistical reports (including its MIB) and in logs.  Since
   the Circuit ID is local only to a particular relay agent, a circuit
   ID should be qualified with the giaddr value that identifies the
   relay agent.


            SubOpt   Len     Circuit ID
           +------+------+------+------+------+------+------+------+--
           |  1   |   n  |  c1  |  c2  |  c3  |  c4  |  c5  |  c6  | ...
           +------+------+------+------+------+------+------+------+--


















Expires April 2001                                              [Page 9]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


3.2 Agent Remote ID Sub-option

   This sub-option MAY be added by DHCP relay agents which terminate
   switched or permanent circuits and have mechanisms to identify the
   remote host end of the circuit.  The Remote ID field may be used to
   encode, for instance:
       -- a "caller ID" telephone number for dial-up connection
       -- a "user name" prompted for by a Remote Access Server
       -- a remote caller ATM address
       -- a "modem ID" of a cable data modem
       -- the remote IP address of a point-to-point link
       -- a remote X.25 address for X.25 connections

   The remote ID MUST be globally unique.

   DHCP servers MAY use this option to select parameters specific to
   particular users, hosts, or subscriber modems. The option SHOULD be
   considered an opaque value, with policies based on exact string match
   only; that is, the option SHOULD NOT be internally parsed by the
   server.

   The relay agent MAY use this field in addition to or instead of the
   Agent Circuit ID field to select the circuit on which to forward the
   DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this
   value in any reports or MIBs associated with a particular client.



            SubOpt   Len     Agent Remote ID
           +------+------+------+------+------+------+------+------+--
           |  2   |   n  |  r1  |  r2  |  r3  |  r4  |  r5  |  r6  | ...
           +------+------+------+------+------+------+------+------+--



















Expires April 2001                                             [Page 10]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


4.0 Issues Resolved

   The DHCP relay agent option resolves several issues in an environment
   in which untrusted hosts access the intervet via a circuit based
   public network. This resolution assumes that all DHCP protocol
   traffic by the public hosts traverse the DHCP relay agent and that
   the IP network between the DHCP relay agent and the DHCP server is
   uncompromised.

   Broadcast Forwarding

      The circuit access equipment forwards the normally broadcasted
      DHCP response only on the circuit indicated in the Agent Circuit
      ID.

   DHCP Address Exhaustion

      In general, the DHCP server may be extended to maintain a database
      with the "triplet" of


                  (client IP address,  client MAC address,  client remote ID)


      The DHCP server SHOULD implement policies that restrict the number
      of IP addresses to be assigned to a single remote ID.


   Static Assignment

      The DHCP server may use the remote ID to select the IP address to
      be assigned.  It may permit static assignment of IP addresses to
      particular remote IDs, and disallow an address request from an
      unauthorized remote ID.


   IP Spoofing

      The circuit access device may associate the IP address assigned by
      a DHCP server in a forwarded DHCP Ack packet with the circuit to
      which it was forwarded. The circuit access device MAY prevent
      forwarding of IP packets with source IP addresses -other than-
      those it has associated with the receiving circuit.  This prevents
      simple IP spoofing attacks on the Central LAN, and IP spoofing of
      other hosts.






Expires April 2001                                             [Page 11]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   Client Identifer Spoofing

      By using the agent-supplied Agent Remote ID option, the untrusted
      and as-yet unstandardized client identifer field need not be used
      by the DHCP server.

   MAC Address Spoofing

      By associating a MAC address with an Agent Remote ID, the DHCP
      server can prevent offering an IP address to an attacker spoofing
      the same MAC address on a different remote ID.

5.0 Security Considerations

   DHCP as currently defined provides no authentication or security
   mechanisms.  Potential exposures to attack are discussed in section 7
   of the DHCP protocol specification in RFC 2131 [1].

   This document introduces mechanisms to address several security
   attacks on the operation of IP address assignment, including IP
   spoofing, Client ID spoofing, MAC address spoofing, and DHCP server
   address exhaustion. It relies on an implied trusted relationship
   between the DHCP Relay Agent and the DHCP server, with an assumed
   untrusted DHCP client.  It introduces a new identifer, the "Remote
   ID", that is also assumed to be trusted. The Remote ID is provided by
   the access network or modem and not by client premise equipment.
   Cryptographic or other techniques to authenticate the remote ID are
   certainly possible and encouraged, but are beyond the scope of this
   document.

   This option is targeted towards environments in which the network
   infrastructure -- the relay agent, the DHCP server, and the entire
   network in which those two devices reside -- is trusted and secure.
   As used in this document, the word "trusted" implies that
   unauthorized DHCP traffic cannot enter the trusted network except
   through secured and trusted relay agents and that all devices
   internal to the network are secure and trusted. Potential deployers
   of this option should give careful consideration to the potential
   security vulnerabilities that are present in this model before
   deploying this option in actual networks.

   Note that any future mechanisms for authenticating DHCP client to
   server communications must take care to omit the DHCP Relay Agent
   option from server authentication calculations. This was the
   principal reason for organizing the DHCP Relay Agent Option as a
   single option with sub-options, and for requiring the relay agent to
   remove the option before forwarding to the client.




Expires April 2001                                             [Page 12]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   While it is beyond the scope of this document to specify the general
   forwarding algorithm of public data circuit access units, note that
   automatic reforwarding of IP or ARP broadcast packets back downstream
   exposes serious IP security risks.  For example, if an upstream
   broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back
   downstream, any public host may easily spoof the desired DHCP server.

6.0 IANA Considerations

   IANA is required to maintain a new number space of "DHCP Relay Agent
   Sub-options", with the initial sub-options as described in this
   document.

   IANA assigns future DHCP Relay Agent Sub-options with a "IETF
   Consensus" policy as described in RFC 2434 [3].  Future proposed
   sub-options are to be referenced symbolically in the internet-drafts
   that describe them, and shall be assigned numeric codes by IANA when
   and if the draft is approved by IESG for Proposed Standard RFC
   status.

7.0 Intellectual Property Notices

   This section contains two notices as required by [5] for standards
   track documents.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.








Expires April 2001                                             [Page 13]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


8.0 References

        [1]     Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
                Bucknell University, March 1997.



        [2]     Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor
                Extension"  RFC 2132.



        [3]     Narten,T. and Alvestrand, H. "Guidelines for Writing an
                IANA Considerations Section in RFCs", RFC 2434.



        [4]     Bradner, S. "Key words for use in RFCs to Indicate Requirement
                Levels", RFC 2119.



        [5]     Bradner, S. "The Internet Standards Process -- Revision 3",
                RFC 2026.



        [6]     Kent, S. and Atkinson, R. "Security Architecture for the
                Internet Protocol", RFS 2401.


9.0 Glossary


           DSLAM   Digital Subscriber Link Access Multiplexer
           IANA    Internet Assigned Numbers Authority
           LIS     Logical IP Subnet
           MAC     Message Authentication Code
           RAS     Remote Access Server

10.0 Author's Address










Expires April 2001                                             [Page 14]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000



               Michael Patrick
               Motorola Broadband Communications Sector
               20 Cabot Blvd., MS M4-30
               Mansfield, MA 02048

               Phone: (508) 261-5707
               Email: michael.patrick@motorola.com











































Expires April 2001                                             [Page 15]



From owner-dhcp-v4@bucknell.edu  Fri Oct 13 14:38: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 OAA10423
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 13 Oct 2000 14:38:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DIX0b21474;
	Fri, 13 Oct 2000 14:33:00 -0400 (EDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9DIVUb15480
	for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 14:31:30 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA04859 for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 11:03:54 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA06183 for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 11:03:54 -0700 (MST)]
Received: from dma.isg.mot.com (cabs2.dma.isg.mot.com [150.21.2.48])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA26166
	for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 14:03:53 -0400 (EDT)
Message-Id: <200010131803.OAA26166@noah.dma.isg.mot.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: "Michael W. Patrick": dhcp agent options draft 12
Date: Fri, 13 Oct 2000 14:03:52 -0400
From: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
Reply-To: mpatrick@dma.isg.mot.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I apologize for not including a "changes" section.  As you 
know, draft 11 passed WG last call. It was rejected by the IESG
because it overstated the security considerations. 
In the meantime, I also received two requests to clarify the
operation.

So here's what's new in rev 12:

1  I added one new paragraph in section 5 Security detailing the environment
   restrictions under which DHCP relay agent option enhances
   security.  This was added at the insistence of the IESG.

2  I added text in section 2.1 clarifying how to handle the "End Option"
   (255).  The previous drafts were not clear when they called
   for making the relay agent option the "last option". 
   You could either 
       1 insert before the End Option 
       2 replace the End option with the relay agent option
         (i.e.  overwrite End option and not have one at all)
       3 put the relay agent option *after* the End option
   and still make a case for complying with the draft.
   This draft says do the *insert*, case 1.
   If there's controversy over this, I'm hesitant to revert back
   to the WG-approved draft 11 wording, because it really is
   ambiguous to require the relay agent option to be the "last
   option". 

3  I added text in section 2.1 clarifying operation of a "trusted
   downstream network element" which may add a relay agent option but
   NOT be a router that set giaddr.  This concept was added before WG
   last call for the DSL folks, who want a DSLAM to set an agent
   option but not be a router hop. The new text clarifies that the
   draft does NOT specify what is trusted and what is not.  
   If there's controversy on the wording I'll revert back to 11.


-mike

------- Forwarded Message

>From owner-dhcp-v4@bucknell.edu  Fri Oct 13 10:31:30 2000
Received: from pobox2.mot.com (pobox2.mot.com [136.182.15.8])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA26161;
	Fri, 13 Oct 2000 10:31:28 -0400 (EDT)
Received: [from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA18400; Fri, 13 Oct 2000 07:31:28 -0700 (MST)]
Received: [from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA25080; Fri, 13 Oct 2000 07:31:26 -0700 (MST)]
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9DETab21851;
	Fri, 13 Oct 2000 10:29:36 -0400 (EDT)
Received: from motgate3.mot.com ([144.189.100.103])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9DERub11458
	for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 10:27:56 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA09252 for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 07:25:15 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA14767 for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 07:27:52 -0700 (MST)]
Received: from dma.isg.mot.com (cabs2.dma.isg.mot.com [150.21.2.48])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA24018
	for <dhcp-v4@bucknell.edu>; Fri, 13 Oct 2000 10:27:51 -0400 (EDT)
Message-Id: <200010131427.KAA24018@noah.dma.isg.mot.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: dhcp agent options draft 12
Date: Fri, 13 Oct 2000 10:27:51 -0400
From: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
Reply-To: mpatrick@dma.isg.mot.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN







INTERNET DRAFT


DHC  Working Grop                                      Michael Patrick
<draft-ietf-dhc-agent-options-12.txt>                  Motorola BCS
                                                       October 11, 2000


                  DHCP Relay Agent Information Option

Status of this Memo


   This document is an Internet Draft and is in full conformance of
   section 10 of RFC2026.  Internet Drafts are working documents of the
   Internet Engineering Task Force (IETF), its Areas, and its Working
   Groups.  Note that other groups may also distribute working documents
   as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shado Directories can be accessed at
   http://ww.ietf.org/shadow.html


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

Abstract

   Newer high-speed public Internet access technologies call for a
   high-speed modem to have a LAN attachment to one or more customer
   premise hosts.  It is advantageous to use the Dynamic Host
   Configuration Protocol as defined in RFC 2131 [1] to assign customer
   premise host IP addresses in this environment. However, a number of
   security and scaling problems arise with such "public" DHCP use.
   This document describes a new DHCP option to address these issues.
   This option extends the set of DHCP options as defined in RFC 2132
   [2].




Expires April 2001                                              [Page 1]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   The new option is called the Relay Agent Information option and is
   inserted by the DHCP relay agent when forwarding client-originated
   DHCP packets to a DHCP server.  Servers recognizing the Relay Agent
   Information option may use the information to implement IP address or
   other parameter assignment policies. The DHCP Server echoes the
   option back verbatim to the relay agent in server-to-client replies,
   and the relay agent strips the option before forwarding the reply to
   the client.

   The "Relay Agent Information" option is organized as a single DHCP
   option that contains one or more "sub-options" that convey
   information known by the relay agent.  The initial sub-options are
   defined for a relay agent that is co-located in a public circuit
   access unit.  These include a "circuit ID" for the incoming circuit,
   and a "remote ID" which provides a trusted identifier for the remote
   high-speed modem.

Table of Contents

        1   Introduction........................................... 2
        1.1 High-Speed Circuit Switched Data Networks.............. 2
        1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4
        2.0 Relay Agent Information Option......................... 5
        2.1 Agent Operation........................................ 6
        2.1.1 Reforwarded DHCP requests............................ 7
        2.2 Server Operation....................................... 7
        3.0 Relay Agent Information Suboptions..................... 8
        3.1 Agent Circuit ID....................................... 8
        3.2 Agent Remote ID........................................ 9
        4.0 Issues Resolved........................................ 10
        5.0 Security Considerations................................ 11
        6.0 IANA Considerations.................................... 11
        7.0 Intellectual Property Notice........................... 12
        8.0 References............................................. 12
        9.0 Glossary............................................... 13
        10.0 Author's Address...................................... 13



1   Introduction

1.1 High-Speed Circuit Switched Data Networks

   Public Access to the Internet is usually via a circuit switched data
   network.  Today, this is primarily implemented with dial-up modems
   connecting to a Remote Access Server.  But higher speed circuit
   access networks also include ISDN, ATM, Frame Relay, and Cable Data
   Networks.  All of these networks can be characterized as a "star"



Expires April 2001                                              [Page 2]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   topology where multiple users connect to a "circuit access unit" via
   switched or permanent circuits.

   With dial-up modems, only a single host PC attempts to connect to the
   central point.  The PPP protocol is widely used to assign IP
   addresses to be used by the single host PC.

   The newer high-speed circuit technologies, however, frequently
   provide a LAN interface (especially Ethernet) to one or more host
   PCs.  It is desirable to support centralized assignment of the IP
   addresses of host computers connecting on such circuits via DHCP.
   The DHCP server can be, but usually is not, co-implemented with the
   centralized circuit concentration access device.  The DHCP server is
   often connected as a separate server on the "Central LAN" to which
   the central access device (or devices) attach.

   A common physical model for high-speed Internet circuit access is
   shown in Figure 1, below.




                      +---------------+                          |
        Central       |   Circuit     |-- ckt 1--- Modem1-- Host-|- Host A
        LAN     |     |   Access      |                     Lan  |- Host B
                |     |   Unit 1      |                          |- Host C
                |-----|               |--                        |
                |     |(relay agent)  |...
   +---------+  |     +---------------+
   |  DHCP   |--|
   | Server  |  |
   +---------+  |
                |
                |     +---------------+
   +---------+  |     |   Circuit     |-- ckt 1--- Modem2-- Host--- Host D
   | Other   |  |     |   Access      |                     Lan
   | Servers |--|-----|   Unit 2      |
   |  (Web,  |  |     |               |-- ckt 2--- Modem3-- Host--- Host E
   |   DNS)  |  |     |(relay agent)  |...                  Lan
   |         |        +---------------+
   +---------+
            Figure 1:  DHCP High Speed Circuit Access Model


   Note that in this model, the "modem" connects to a LAN at the user
   site, rather than to a single host. Multiple hosts are implemented at
   this site.  Although it is certainly possible to implement a full IP
   router at the user site, this requires a relatively expensive piece



Expires April 2001                                              [Page 3]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   of equipment (compared to typical modem costs).  Furthermore, a
   router requires an IP address not only for every host, but for the
   router itself. Finally, a user-side router requires a dedicated
   Logical IP Subnet (LIS) for each user.  While this model is
   appropriate for relatively small corporate networking environments,
   it is not appropriate for large, public accessed networks. In this
   scenario, it is advantageous to implement an IP networking model that
   does not allocate an IP address for the modem (or other networking
   equipment device at the user site), and especially not an entire LIS
   for the user side LAN.

   Note that using this method to obtain IP addresses means that IP
   addresses can only be obtained while communication to the central
   site is available. Some host lan installations may use a local DHCP
   server or other methods to obtain IP addresses for in-house use.

1.2 DHCP Relay Agent in the Circuit Access Unit

   It is desirable to use DHCP to assign the IP addresses for public
   high-speed circuit access.  A number of circuit access units (e.g.
   RAS's, cable modem termination systems, ADSL access units, etc)
   connect to a LAN (or local internet) to which is attached a DHCP
   server.

   For scaling and security reasons, it is advantageous to implement a
   "router hop" at the circuit access unit, much like high-capacity
   RAS's do today.  The circuit access equipment acts as both a router
   to the circuits and as the DHCP relay agent.

   The advantages of co-locating the DHCP relay agent with the circuit
   access equipment are:

   DHCP broadcast replies can be routed to only the proper circuit,
   avoiding, say, the replication of the DCHP reply broadcast onto
   thousands of access circuits;

   The same mechanism used to identify the remote connection of the
   circuit (e.g. a user ID requested by a Remote Access Server acting as
   the circuit access equipment) may be used as a host identifier by
   DHCP, and used for parameter assignment.  This includes centralized
   assignment of IP addresses to hosts.  This provides a secure remote
   ID from a trusted source -- the relay agent.

   A number of issues arise when forwarding DHCP requests from hosts
   connecting publicly accessed high-speed circuits with LAN connections
   at the host. Many of these are security issues arising from DHCP
   client requests from untrusted sources.  How does the relay agent
   know to which circuit to forward replies?  How does the system



Expires April 2001                                              [Page 4]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   prevent  DHCP IP exhaustion attacks?  This is when an attacker
   requests all available IP addresses from a DHCP server by sending
   requests with fabricated client MAC addresses.  How can an IP address
   or LIS be permanently assigned to a particular user or modem?  How
   does one prevent "spoofing" of client identifer fields used to assign
   IP addresses?  How does one prevent denial of service by "spoofing"
   other client's MAC addresses?

   All of these issues may be addressed by having the circuit access
   equipment, which is a trusted component, add information to DHCP
   client requests that it forwards to the DHCP server.

2.0 Relay Agent Information Option

   This document defines a new DHCP Option called the Relay Agent
   Information Option.  It is a "container" option for specific agent-
   supplied sub-options.  The format of the Relay Agent Information
   option is:


            Code   Len     Agent Information Field
           +------+------+------+------+------+------+--...-+------+
           |  82  |   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |
           +------+------+------+------+------+------+--...-+------+

   The length N gives the total number of octets in the Agent
   Information Field. The Agent Information field consists of a sequence
   of SubOpt/Length/Value tuples for each sub-option, encoded in the
   following manner:


            SubOpt  Len     Sub-option Value
           +------+------+------+------+------+------+--...-+------+
           |  1   |   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |
           +------+------+------+------+------+------+--...-+------+
            SubOpt  Len     Sub-option Value
           +------+------+------+------+------+------+--...-+------+
           |  2   |   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |
           +------+------+------+------+------+------+--...-+------+


   No "pad" sub-option is defined, and the Information field shall NOT
   be terminated with a 255 sub-option.  The length N of the DHCP Agent
   Information Option shall include all bytes of the sub-option
   code/length/value tuples. Since at least one sub-option must be
   defined, the minimum Relay Agent Information length is two (2).  The
   length N of the sub-options shall be the number of octets in only
   that sub-option's value field.  A sub-option length may be zero.  The



Expires April 2001                                              [Page 5]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   sub-options need not appear in sub-option code order.


   The initial assignment of DHCP Relay Agent Sub-options is as follows:


                   DHCP Agent              Sub-Option Descrption
                   Sub-option Code
                   ---------------         ----------------------
                       1                   Agent Circuit ID Sub-option
                       2                   Agent Remote ID Sub-option



2.1 Agent Operation

   Overall adding of the DHCP relay agent option SHOULD be configurable,
   and SHOULD be disabled by default. Relay agents SHOULD have separate
   configurables for each sub-option to control whether it is added to
   client-to-server packets.

   A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last option (but before 'End Option' 255, if present) in
   the DHCP options field of any recognized BOOTP or DHCP packet
   forwarded from a client to a server.

   Relay agents receiving a DHCP packet from an untrusted circuit with
   giaddr set to zero (indicating that they are the first-hop router)
   but with a Relay Agent Information option already present in the
   packet SHALL discard the packet and increment an error count.  A
   trusted circuit may contain a trusted downstream (closer to client)
   network element (bridge) between the relay agent and the client that
   MAY add a relay agent option but not set the giaddr field.  In this
   case, the relay agent does NOT add a "second" relay agent option, but
   forwards the DHCP packet per normal DHCP relay agent operations,
   setting the giaddr field as it deems appropriate.

   The mechanisms for distinguishing between "trusted" and "untrusted"
   circuits are specific to the type of circuit termination equipment,
   and may involve local administration. For example, a Cable Modem
   Termination System may consider upstream packets from most cable
   modems as "untrusted", but an ATM switch terminating VCs switched
   through a DSLAM may consider such VCs as "trusted" and accept a relay
   agent option added by the DSLAM.

   Relay agents MAY have a configurable for the maximum size of the DHCP
   packet to be created after appending the Agent Information option.
   Packets which, after appending the Relay Agent Information option,



Expires April 2001                                              [Page 6]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   would exceed this configured maximum size shall be forwarded WITHOUT
   adding the Agent Information option. An error counter SHOULD be
   incremented in this case.  In the absence of this configurable, the
   agent SHALL NOT increase a forwarded DHCP packet size to exceed the
   MTU of the interface on which it is forwarded.

   The Relay Agent Information option echoed by a server MUST be removed
   by either the relay agent or the trusted downstream network element
   which added it when forwarding a server-to-client response back to
   the client.

   The agent SHALL NOT add an "Option Overload" option to the packet or
   use the "file" or "sname" fields for adding Relay Agent Information
   option.  It SHALL NOT parse or remove Relay Agent Information options
   that may appear in the sname or file fields of a server-to-client
   packet forwarded through the agent.

   The operation of relay agents for specific sub-options is specified
   with that sub-option.

   Relay agents are NOT required to monitor or modify client-originated
   DHCP packets addressed to a server unicast address. This  includes
   the DHCP-REQUEST sent when entering the RENEWING state.

   Relay agents MUST NOT modify DHCP packets that use the IPSEC
   Authentication Header or IPSEC Encapsulating Security Payload [6].

2.1.1 Reforwarded DHCP requests

   A DHCP relay agent may receive a client DHCP packet forwarded from a
   BOOTP/DHCP relay agent closer to the client. Such a packet will have
   giaddr as non-zero, and may or may not already have a DHCP Relay
   Agent option in it.

   Relay agents configured to add a Relay Agent option which receive a
   client DHCP packet with a nonzero giaddr SHALL discard the packet if
   the giaddr spoofs a giaddr address implemented by the local agent
   itself.

   Otherwise, the relay agent SHALL forward any received DHCP packet
   with a valid non-zero giaddr WITHOUT adding any relay agent options.
   Per RFC 2131, it shall also NOT modify the giaddr value.


2.2     Server Operation

   DHCP servers unaware of the Relay Agent Information option will
   ignore the option upon receive and will not echo it back on



Expires April 2001                                              [Page 7]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   responses.  This is the specified server behavior for unknown
   options.

   DHCP servers claiming to support the Relay Agent Information option
   SHALL echo the entire contents of the Relay Agent Information option
   in all replies.  Servers SHOULD copy the Relay Agent Information
   option as the last DHCP option in the response.  Servers SHALL NOT
   place the echoed Relay Agent Information option in the overloaded
   sname or file fields.  If a server is unable to copy a full Relay
   Agent Information field into a response, it SHALL send the response
   without the Relay Information Field, and SHOULD increment an error
   counter for the situation.

   The operation of DHCP servers for specific sub-options is specified
   with that sub-option.

   Note that DHCP relay agents are not required to monitor unicast DHCP
   messages sent directly between the client and server (i.e, those that
   aren't sent via a relay agent). However, some relay agents MAY chose
   to do such monitoring and add relay agent options. Consequently,
   servers SHOULD be prepared to handle relay agent options in unicast
   messages, but MUST NOT expect them to always be there.





























Expires April 2001                                              [Page 8]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


3.0 Relay Agent Information Sub-options

3.1 Agent Circuit ID Sub-option

   This sub-option MAY be added by DHCP relay agents which terminate
   switched or permanent circuits.  It encodes an agent-local identifier
   of the circuit from which a DHCP client-to-server packet was
   received.  It is intended for use by agents in relaying DHCP
   responses back to the proper circuit.  Possible uses of this field
   include
       - Router interface number
       - Switching Hub port number
       - Remote Access Server port number
       - Frame Relay DLCI
       - ATM virtual circuit number
       - Cable Data virtual circuit number

   Servers MAY use the Circuit ID for IP and other parameter assignment
   policies. The Circuit ID SHOULD be considered an opaque value, with
   policies based on exact string match only; that is, the Circuit ID
   SHOULD NOT be internally parsed by the server.

   The DHCP server SHOULD report the Agent Circuit ID value of current
   leases in statistical reports (including its MIB) and in logs.  Since
   the Circuit ID is local only to a particular relay agent, a circuit
   ID should be qualified with the giaddr value that identifies the
   relay agent.


            SubOpt   Len     Circuit ID
           +------+------+------+------+------+------+------+------+--
           |  1   |   n  |  c1  |  c2  |  c3  |  c4  |  c5  |  c6  | ...
           +------+------+------+------+------+------+------+------+--


















Expires April 2001                                              [Page 9]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


3.2 Agent Remote ID Sub-option

   This sub-option MAY be added by DHCP relay agents which terminate
   switched or permanent circuits and have mechanisms to identify the
   remote host end of the circuit.  The Remote ID field may be used to
   encode, for instance:
       -- a "caller ID" telephone number for dial-up connection
       -- a "user name" prompted for by a Remote Access Server
       -- a remote caller ATM address
       -- a "modem ID" of a cable data modem
       -- the remote IP address of a point-to-point link
       -- a remote X.25 address for X.25 connections

   The remote ID MUST be globally unique.

   DHCP servers MAY use this option to select parameters specific to
   particular users, hosts, or subscriber modems. The option SHOULD be
   considered an opaque value, with policies based on exact string match
   only; that is, the option SHOULD NOT be internally parsed by the
   server.

   The relay agent MAY use this field in addition to or instead of the
   Agent Circuit ID field to select the circuit on which to forward the
   DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this
   value in any reports or MIBs associated with a particular client.



            SubOpt   Len     Agent Remote ID
           +------+------+------+------+------+------+------+------+--
           |  2   |   n  |  r1  |  r2  |  r3  |  r4  |  r5  |  r6  | ...
           +------+------+------+------+------+------+------+------+--



















Expires April 2001                                             [Page 10]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


4.0 Issues Resolved

   The DHCP relay agent option resolves several issues in an environment
   in which untrusted hosts access the intervet via a circuit based
   public network. This resolution assumes that all DHCP protocol
   traffic by the public hosts traverse the DHCP relay agent and that
   the IP network between the DHCP relay agent and the DHCP server is
   uncompromised.

   Broadcast Forwarding

      The circuit access equipment forwards the normally broadcasted
      DHCP response only on the circuit indicated in the Agent Circuit
      ID.

   DHCP Address Exhaustion

      In general, the DHCP server may be extended to maintain a database
      with the "triplet" of


                  (client IP address,  client MAC address,  client remote ID)


      The DHCP server SHOULD implement policies that restrict the number
      of IP addresses to be assigned to a single remote ID.


   Static Assignment

      The DHCP server may use the remote ID to select the IP address to
      be assigned.  It may permit static assignment of IP addresses to
      particular remote IDs, and disallow an address request from an
      unauthorized remote ID.


   IP Spoofing

      The circuit access device may associate the IP address assigned by
      a DHCP server in a forwarded DHCP Ack packet with the circuit to
      which it was forwarded. The circuit access device MAY prevent
      forwarding of IP packets with source IP addresses -other than-
      those it has associated with the receiving circuit.  This prevents
      simple IP spoofing attacks on the Central LAN, and IP spoofing of
      other hosts.






Expires April 2001                                             [Page 11]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   Client Identifer Spoofing

      By using the agent-supplied Agent Remote ID option, the untrusted
      and as-yet unstandardized client identifer field need not be used
      by the DHCP server.

   MAC Address Spoofing

      By associating a MAC address with an Agent Remote ID, the DHCP
      server can prevent offering an IP address to an attacker spoofing
      the same MAC address on a different remote ID.

5.0 Security Considerations

   DHCP as currently defined provides no authentication or security
   mechanisms.  Potential exposures to attack are discussed in section 7
   of the DHCP protocol specification in RFC 2131 [1].

   This document introduces mechanisms to address several security
   attacks on the operation of IP address assignment, including IP
   spoofing, Client ID spoofing, MAC address spoofing, and DHCP server
   address exhaustion. It relies on an implied trusted relationship
   between the DHCP Relay Agent and the DHCP server, with an assumed
   untrusted DHCP client.  It introduces a new identifer, the "Remote
   ID", that is also assumed to be trusted. The Remote ID is provided by
   the access network or modem and not by client premise equipment.
   Cryptographic or other techniques to authenticate the remote ID are
   certainly possible and encouraged, but are beyond the scope of this
   document.

   This option is targeted towards environments in which the network
   infrastructure -- the relay agent, the DHCP server, and the entire
   network in which those two devices reside -- is trusted and secure.
   As used in this document, the word "trusted" implies that
   unauthorized DHCP traffic cannot enter the trusted network except
   through secured and trusted relay agents and that all devices
   internal to the network are secure and trusted. Potential deployers
   of this option should give careful consideration to the potential
   security vulnerabilities that are present in this model before
   deploying this option in actual networks.

   Note that any future mechanisms for authenticating DHCP client to
   server communications must take care to omit the DHCP Relay Agent
   option from server authentication calculations. This was the
   principal reason for organizing the DHCP Relay Agent Option as a
   single option with sub-options, and for requiring the relay agent to
   remove the option before forwarding to the client.




Expires April 2001                                             [Page 12]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


   While it is beyond the scope of this document to specify the general
   forwarding algorithm of public data circuit access units, note that
   automatic reforwarding of IP or ARP broadcast packets back downstream
   exposes serious IP security risks.  For example, if an upstream
   broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back
   downstream, any public host may easily spoof the desired DHCP server.

6.0 IANA Considerations

   IANA is required to maintain a new number space of "DHCP Relay Agent
   Sub-options", with the initial sub-options as described in this
   document.

   IANA assigns future DHCP Relay Agent Sub-options with a "IETF
   Consensus" policy as described in RFC 2434 [3].  Future proposed
   sub-options are to be referenced symbolically in the internet-drafts
   that describe them, and shall be assigned numeric codes by IANA when
   and if the draft is approved by IESG for Proposed Standard RFC
   status.

7.0 Intellectual Property Notices

   This section contains two notices as required by [5] for standards
   track documents.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.








Expires April 2001                                             [Page 13]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000


8.0 References

        [1]     Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
                Bucknell University, March 1997.



        [2]     Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor
                Extension"  RFC 2132.



        [3]     Narten,T. and Alvestrand, H. "Guidelines for Writing an
                IANA Considerations Section in RFCs", RFC 2434.



        [4]     Bradner, S. "Key words for use in RFCs to Indicate Requirement
                Levels", RFC 2119.



        [5]     Bradner, S. "The Internet Standards Process -- Revision 3",
                RFC 2026.



        [6]     Kent, S. and Atkinson, R. "Security Architecture for the
                Internet Protocol", RFS 2401.


9.0 Glossary


           DSLAM   Digital Subscriber Link Access Multiplexer
           IANA    Internet Assigned Numbers Authority
           LIS     Logical IP Subnet
           MAC     Message Authentication Code
           RAS     Remote Access Server

10.0 Author's Address










Expires April 2001                                             [Page 14]





<draft-ietf-dhc-agent-options-12.txt>                   October 11, 2000



               Michael Patrick
               Motorola Broadband Communications Sector
               20 Cabot Blvd., MS M4-30
               Mansfield, MA 02048

               Phone: (508) 261-5707
               Email: michael.patrick@motorola.com











































Expires April 2001                                             [Page 15]


------- End of Forwarded Message



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-v4@bucknell.edu  Mon Oct 16 12:05: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 MAA08846
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 16 Oct 2000 12:05:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GG0ob10714;
	Mon, 16 Oct 2000 12:00:50 -0400 (EDT)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GG0nb28217
	for <dhcp-v4@bucknell.edu>; Mon, 16 Oct 2000 12:00:49 -0400 (EDT)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA02277;
	Mon, 16 Oct 2000 16:00:35 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 16 Oct 2000 15:59:18 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <4VB8G5DH>; Mon, 16 Oct 2000 08:59:17 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2CB7@orsmsx35.jf.intel.com>
From: "Hattig, Myron" <myron.hattig@intel.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: cheshire@apple.com
Subject: RE: Status of Autoconfig Draft
Date: Mon, 16 Oct 2000 08:59:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Reply-To: myron.hattig@intel.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I agree completely with Bernard. The draft has great value, but I'm uneasy
with it in its current form. The uneasiness comes from suggesting new things
(scope addressing for IPv4) and documenting current implementations (autonet
in windows & macOS). Separation of topics allows a discussion to take place
on the new ideas. I've been slow to start a discussion on the new ideas in
part because I'd like to see autonet clearly documented in an RFC.

-myron

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: Sunday, October 08, 2000 1:21 PM
> To: DHCPv4 discussion list
> Cc: DHCPv4 discussion list; cheshire@apple.com
> Subject: RE: Status of Autoconfig Draft
> 
> 
> >We should have two parallel drafts (standards
> >track and informational, respectively) that proceed 
> >independently.  I think that's a bad idea, as some folks 
> >will get confused and implement the legacy version where 
> >we'd really like them to implement the standard one in the 
> >future.
> 
> The confusion arises from the fact that 
> draft-dhc-ipv4-autoconf-05.txt today combines description
> of existing practice along with recommendations on future
> implementations. I would recommend that all portions
> of the draft referring to non-implemented functionality
> (such as the DHCP option for control of auto-config 
> behavior) be removed, and that the draft state clearly that it
> is not a standards track document. The new draft would
> focus solely on documenting the functionality shipped
> in MacOS and Windows. It is also ok if this draft were
> to point out various weaknesses of the legacy approach. 
> 
> We could then move forward with a separate standards
> track document. 
> 
> 



From owner-dhcp-v4@bucknell.edu  Mon Oct 16 12:09: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 MAA08927
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 16 Oct 2000 12:09:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GG7Hb09981;
	Mon, 16 Oct 2000 12:07:17 -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 e9GG7Eb31603
	for <dhcp-v4@bucknell.edu>; Mon, 16 Oct 2000 12:07:14 -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 MAA22845; Mon, 16 Oct 2000 12:06:57 -0400 (EDT)
Message-Id: <4.2.0.58.20001016115017.01c0bb00@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 16 Oct 2000 12:07:48 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: Failover draft conference call -- next week!
Cc: kkinnear@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: kkinnear@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


	
*****
** Conference Call Announcement to discuss the
** Failover draft -- you *must* reply to participate!
*****

It is getting to be time to move the failover draft toward last
call, and so we are planning to have a conference call prior to
revising it before the San Deigo IETF in order to explore any
issues that remain with the current draft.

The current draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-07.txt
  

The proposal is that we have a single, three hour conference call
on Friday October 27, and if necessary, a followup on the
Friday following, November 3.

Proposal:

     Call 1:      Friday October 27, 2000 12pm-3pm EST

	and if necessary:

     Call 2:      Friday, November 3, 2000 12pm-3pm EST

This is not an interim working group meeting (in IETF parlance),
but rather a "design group" meeting.  This means that any
decisions made have to be ratified by the entire working group
(which is how we've always done it anyway).

**************************************************
         Conference Call Announcement
        YOU MUST REPLY TO PARTICIPATE
    (I have to reserved conference call slots)
**************************************************

If you want to participate, I need email from you with answers to
the following questions:

   1.  Your name(s), affiliation, and TIME ZONE.

   2.  The topics in the current failover draft which you would
   like to discuss in a conference call.  Please order a list by
   priority.  Examples might be: conflict resolution,
   initialization between partner servers, etc.

   3.  Will the above dates work for you?  If not, please make
   some alternative proposals -- recognizing that time is short.

These will be toll free calls inside of the continental US. If
you are outside of the toll free area, and would need financial
assistance as a condition of participation in such a call, please
mention that and we'll see what we can work out.

Send your reply *only* to kkinnear@cisco.com (i.e., do *not*
reply to the whole dhcp-v4 list!).

************************************************

Along about Friday October 20, I'll let all of the respondents
know if the proposed dates worked, schedule the actual phone
calls if they did, and distribute the phone numbers.

Anyone will be able to participate after that time (after they
contact me) of course.

Cheers -- Kim

Kim Kinnear
Cisco Systems
Chelmsford, MA 01824

(978) 244-8376
kkinnear@cisco.com



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-v4@bucknell.edu  Mon Oct 16 13:28: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 NAA11356
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 16 Oct 2000 13:28:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9GHPqb01229;
	Mon, 16 Oct 2000 13:25:52 -0400 (EDT)
Received: from crash.ab.videon.ca (crash.ab.videon.ca [206.75.216.220])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9GHPbb26377
	for <dhcp-v4@bucknell.edu>; Mon, 16 Oct 2000 13:25:38 -0400 (EDT)
Received: from videdmexg1.ab.videon.ca (videdmexg1.ab.videon.ca [24.108.62.15])
	by crash.ab.videon.ca (8.9.2/8.9.2) with ESMTP id LAA12992
	for <dhcp-v4@bucknell.edu>; Mon, 16 Oct 2000 11:25:20 -0600 (MDT)
Received: by videdmexg1.ab.videon.ca with Internet Mail Service (5.5.2650.21)
	id <42MR4JAW>; Mon, 16 Oct 2000 11:26:34 -0600
Message-ID: <D71A0B584883D4118B4800508BEF3F0A04FEFB@videdmexg1.ab.videon.ca>
From: Laurence Brockman <L.Brockman@videon.ca>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Which is the most stable version of ISC DHCP ver 3 beta?
Date: Mon, 16 Oct 2000 11:26:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: L.Brockman@videon.ca
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Subject says most of it. We are looking for the added features of version 3
and I'm wondering which patchlevel is the most stable (The latest I'm
assuming).

Anyways, any input would be great.

Laurence

--
Laurence Brockman
Unix Administrator
Videon Cablesystems Alberta Inc
10450-178 St.
Edmonton, AB
T5S 1S2
l.brockman@videon.ca
(780) 486-6527



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-v4@bucknell.edu  Mon Oct 16 23:31: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 XAA21281
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 16 Oct 2000 23:31:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9H3R8b09766;
	Mon, 16 Oct 2000 23:27: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 e9H3R5b18621
	for <dhcp-v4@bucknell.edu>; Mon, 16 Oct 2000 23:27:05 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-201.ip.theriver.com [206.97.58.201]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id e9H3QUL06196; Mon, 16 Oct 2000 20:26:30 -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 e9H3Nus05140; Mon, 16 Oct 2000 20:23:57 -0700 (MST)
Message-Id: <200010170323.e9H3Nus05140@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Failover draft conference call -- next week! 
In-Reply-To: Message from Kim Kinnear <kkinnear@cisco.com> 
   of "Mon, 16 Oct 2000 12:07:48 -0400." <4.2.0.58.20001016115017.01c0bb00@funnel.cisco.com> 
Date: Mon, 16 Oct 2000 20:23:56 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I'm going to be in retreat until November 6, so I won't be able to
attend either of those conference calls.   :'(

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Thu Oct 19 12:36: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 MAA23921
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 19 Oct 2000 12:36:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JGUib18065;
	Thu, 19 Oct 2000 12:30:44 -0400 (EDT)
Received: from quadntweb.quadritek.com ([198.200.138.211])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JGU9b13482
	for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 12:30:10 -0400 (EDT)
Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35)
          with SMTP id com for <dhcp-v4@bucknell.edu>;
          Thu, 19 Oct 2000 12:20:12 -0400
From: "A. Gregory Rabil" <grabil@lucent.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed Standard
Date: Thu, 19 Oct 2000 12:30:45 -0400
Message-ID: <00b201c039e9$eee5e1a0$fe8ac8c6@quadritek.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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <01be01c033cf$e482ad30$fe8ac8c6@quadritek.com>
Reply-To: grabil@lucent.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----
From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
Behalf Of A. Gregory Rabil
Sent: Wednesday, October 11, 2000 6:09 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.



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-v4@bucknell.edu  Thu Oct 19 16:48: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 QAA07639
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 19 Oct 2000 16:48:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JKkgb20419;
	Thu, 19 Oct 2000 16:46:42 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@[45.210.200.115])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JKkVb10905
	for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 16:46:31 -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 QAA01310;
	Wed, 18 Oct 2000 16:43:49 -0400
Message-Id: <200010182043.QAA01310@hygro.adsl.duke.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12 
In-Reply-To: Message from "Michael W. Patrick" <mpatrick@dma.isg.mot.com> 
   of "Fri, 13 Oct 2000 14:03:52 EDT." <200010131803.OAA26166@noah.dma.isg.mot.com> 
Date: Wed, 18 Oct 2000 16:43:48 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Mike,

> 1  I added one new paragraph in section 5 Security detailing the environment
>    restrictions under which DHCP relay agent option enhances
>    security.  This was added at the insistence of the IESG.

Yep, thanks.

> 2  I added text in section 2.1 clarifying how to handle the "End Option"
>    (255).  The previous drafts were not clear when they called
>    for making the relay agent option the "last option". 
>    You could either 
>        1 insert before the End Option 
>        2 replace the End option with the relay agent option
>          (i.e.  overwrite End option and not have one at all)
>        3 put the relay agent option *after* the End option
>    and still make a case for complying with the draft.
>    This draft says do the *insert*, case 1.
>    If there's controversy over this, I'm hesitant to revert back
>    to the WG-approved draft 11 wording, because it really is
>    ambiguous to require the relay agent option to be the "last
>    option".

I'm going to demonstrate my lack of understanding about DHCP by asking
what the "end" option is actually used for. I couldn't quite figure it
out from a quick scan of the rfcs. Who inserts it and when?

I would have thought you want the agent options to be the very last
one. Easy to append, easy to strip off. No need to move options
around. But I've seen no followup, so I guess this isn't really an
issue in practice.

Thomas



From owner-dhcp-v4@bucknell.edu  Thu Oct 19 18:19: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 SAA17590
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 19 Oct 2000 18:19:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JMGrb07062;
	Thu, 19 Oct 2000 18:16:53 -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 e9JMGnb00829
	for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 18:16:49 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2T1A>; Thu, 19 Oct 2000 18:16:33 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607129@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: "Michael W. Patrick": dhcp agent options draft 12
Date: Thu, 19 Oct 2000 18:16:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

In RFC 2131, in section 4.1 it states:

   DHCP clients and servers both construct DHCP messages by filling in
   fields in the fixed format section of the message and appending
   tagged data items in the variable length option area.  The options
   area includes first a four-octet 'magic cookie' (which was described
   in section 3), followed by the options.  The last option must always
   be the 'end' option.

And, in RFC 2132, section 3.2 defines the 'end' option:

3.2. End Option

   The end option marks the end of valid information in the vendor
   field.  Subsequent octets should be filled with pad options.

   The code for the end option is 255, and its length is 1 octet.

    Code
   +-----+
   | 255 |
   +-----+

So, I agree with Michael on the change. I haven't gone back to look at the
revised draft (12), but I guess it is best to say:

"MUST insert the option immediately before the end option or after the last
option
 if there is no end option (and in the later case, no end option should be
added)"

Note that RFC 2131 does not use "MUST", just "must": The last option must
always be the 'end' option.

Perhaps this is one to add to the list of corrections? Not also how does
this impact the authentication drafts - since authentication is not to cover
the relay agent option but it might need to cover the end option. The
authentication drafts hopefully just say to remove the relay agent option?

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Wednesday, October 18, 2000 4:44 PM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12


Mike,

> 1  I added one new paragraph in section 5 Security detailing the
environment
>    restrictions under which DHCP relay agent option enhances
>    security.  This was added at the insistence of the IESG.

Yep, thanks.

> 2  I added text in section 2.1 clarifying how to handle the "End Option"
>    (255).  The previous drafts were not clear when they called
>    for making the relay agent option the "last option". 
>    You could either 
>        1 insert before the End Option 
>        2 replace the End option with the relay agent option
>          (i.e.  overwrite End option and not have one at all)
>        3 put the relay agent option *after* the End option
>    and still make a case for complying with the draft.
>    This draft says do the *insert*, case 1.
>    If there's controversy over this, I'm hesitant to revert back
>    to the WG-approved draft 11 wording, because it really is
>    ambiguous to require the relay agent option to be the "last
>    option".

I'm going to demonstrate my lack of understanding about DHCP by asking
what the "end" option is actually used for. I couldn't quite figure it
out from a quick scan of the rfcs. Who inserts it and when?

I would have thought you want the agent options to be the very last
one. Easy to append, easy to strip off. No need to move options
around. But I've seen no followup, so I guess this isn't really an
issue in practice.

Thomas



From owner-dhcp-v4@bucknell.edu  Thu Oct 19 19:10:15 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 TAA23137
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 19 Oct 2000 19:10:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9JN7Kb20577;
	Thu, 19 Oct 2000 19:07:20 -0400 (EDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9JN75b28904
	for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 19:07:05 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA17931 for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 16:07:04 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA27713 for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 16:07:04 -0700 (MST)]
Received: from dma.isg.mot.com (cabs2.dma.isg.mot.com [150.21.2.48])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id TAA07347;
	Thu, 19 Oct 2000 19:07:03 -0400 (EDT)
Message-Id: <200010192307.TAA07347@noah.dma.isg.mot.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>, docsis-macup@cablelabs.com
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12 
In-reply-to: Your message of "Wed, 18 Oct 2000 16:43:48 EDT."
             <200010182043.QAA01310@hygro.adsl.duke.edu> 
Date: Thu, 19 Oct 2000 19:07:03 -0400
From: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
Reply-To: mpatrick@dma.isg.mot.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Tom,

The END issue came up because one relay agent vendor chose to 
*overwrite* the client-inserted END option with the relay
agent option.  IMO, this was a reasonable design decision
given the pre-12 wording.

I checked the Auth draft, and it explicitly
says to include all options in order EXCLUDING any relay
agent options (type 82) that may be present.  So the
auth draft doesn't care where the 82 option is (either
before or after END).  The auth draft does, however, care
very much whether the END option got stripped, because the END is
included in the authentication.

So I added wording stating that the END option must be left alone,
if present:

   A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last option (but before 'End Option' 255, if present) in
   the DHCP options field of any recognized BOOTP or DHCP packet
   forwarded from a client to a server.

I'm in private discussions with the vendor I mentioned to make sure
they agree to the current wording (and the need to change their
implementation).

-mike





>>>>> "Thomas" == Thomas Narten <narten@raleigh.ibm.com> writes:


> Mike,
>> 1 I added one new paragraph in section 5 Security detailing the
>> environment restrictions under which DHCP relay agent option
>> enhances security.  This was added at the insistence of the IESG.

> Yep, thanks.

>> 2 I added text in section 2.1 clarifying how to handle the "End
>> Option" (255).  The previous drafts were not clear when they called
>> for making the relay agent option the "last option".  You could
>> either 1 insert before the End Option 2 replace the End option with
>> the relay agent option (i.e.  overwrite End option and not have one
>> at all) 3 put the relay agent option *after* the End option and
>> still make a case for complying with the draft.  This draft says do
>> the *insert*, case 1.  If there's controversy over this, I'm
>> hesitant to revert back to the WG-approved draft 11 wording,
>> because it really is ambiguous to require the relay agent option to
>> be the "last option".

> I'm going to demonstrate my lack of understanding about DHCP by
> asking what the "end" option is actually used for. I couldn't quite
> figure it out from a quick scan of the rfcs. Who inserts it and
> when?

> I would have thought you want the agent options to be the very last
> one. Easy to append, easy to strip off. No need to move options
> around. But I've seen no followup, so I guess this isn't really an
> issue in practice.

> Thomas



From owner-dhcp-v4@bucknell.edu  Thu Oct 19 21:50:20 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 VAA14333
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 19 Oct 2000 21:50:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9K1iOb29926;
	Thu, 19 Oct 2000 21:44:25 -0400 (EDT)
Received: from neimail.networkengines.com (wks7.networkengines.com [64.55.6.7] (may be forged))
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9K1iDb13470
	for <dhcp-v4@bucknell.edu>; Thu, 19 Oct 2000 21:44:14 -0400 (EDT)
Received: by neimail.networkengines.com with Internet Mail Service (5.5.2650.21)
	id <VBCJ51TB>; Thu, 19 Oct 2000 21:42:09 -0400
Message-ID: <8D18C4F9CBA1D311900F00A0C990C97FD862C5@neimail.networkengines.com>
From: Steve Gonczi <Steve.Gonczi@networkengines.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: "Michael W. Patrick": dhcp agent options draft 12 
Date: Thu, 19 Oct 2000 19:38: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: Steve.Gonczi@networkengines.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>I'm going to demonstrate my lack of understanding about DHCP by asking
>what the "end" option is actually used for. I couldn't quite figure it
>out from a quick scan of the rfcs. Who inserts it and when?

The DHCP server adds it, as the last option.
It merely indicates "there are no more options after this" 
(sort of like a period, closing a sentence). This is a MUST
in RFC 2131.

/sG



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 03:05: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 DAA14065
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 03:05:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9K71ab02449;
	Fri, 20 Oct 2000 03:01:36 -0400 (EDT)
Received: from exchange.northstream.se ([62.20.120.197])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9K71Sb12649
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 03:01:29 -0400 (EDT)
Received: by NS-EXCHANGE-SE with Internet Mail Service (5.5.2650.21)
	id <45ZJJJK8>; Fri, 20 Oct 2000 09:01:55 +0200
Message-ID: <93E299DA8B7DD411904300D0B7D4834305CD49@NS-EXCHANGE-SE>
From: Jerome Privat <jerome.privat@northstream.se>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: "'annd@Exchange.Microsoft.com'" <annd@Exchange.Microsoft.com>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	tandard
Date: Fri, 20 Oct 2000 09:01:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: jerome.privat@northstream.se
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Greg,

Implementation for existing Microsoft 2000 clients was written well before
the User Class was accepted as Proposed Standard (which just happenned now).
So it is normal it does not support what is in the spec now (the same is
true for other pre-standard implementations).

That being said, the syntax in the draft was discussed with people from
Microsoft (Ann Demirtjis at the time, who co-authored the draft). So I would
expect next versions of MS clients to adhere to the spec.

Jerome

Jerome Privat
Northstream AB

-----Original Message-----
From: grabil@lucent.com [mailto:grabil@lucent.com]
Sent: Thursday, October 19, 2000 6:30 PM
To: dhcp-v4@bucknell.edu
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----
From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
Behalf Of A. Gregory Rabil
Sent: Wednesday, October 11, 2000 6:09 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 04:09: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 EAA20996
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 04:09:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9K86Nb01803;
	Fri, 20 Oct 2000 04:06:23 -0400 (EDT)
Received: from bofur.cca.cz (bofur.cca.cz [194.212.149.10])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9K86Fb06337
	for <DHCP-V4@BUCKNELL.EDU>; Fri, 20 Oct 2000 04:06:15 -0400 (EDT)
Received: from pc023.cca.cz (pc023.cca.cz [194.212.149.72])
	by bofur.cca.cz (8.11.0/8.11.0) with ESMTP id e9K861e05662
	for <DHCP-V4@BUCKNELL.EDU>; Fri, 20 Oct 2000 10:06:01 +0200
From: Antonin.Novak@cca.cz
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF96E0FD47.4A37872D-ONC125697E.0029CDB5@cca.cz>
Date: Fri, 20 Oct 2000 10:05:59 +0200
X-MIMETrack: Serialize by Notes Client on
 =?iso-8859-2?q?Anton=EDn_Ch_Novak=2FPlzen=2FCCA=28Release_5=2E0=2E3_=28?=
 =?us-ascii?q?Intl?= =?us-ascii?q?=29|?= =?us-ascii?q?21?= March 2000) at
 20.10.2000 10:05:59,
	Serialize complete at 20.10.2000 10:05:59
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: Antonin.Novak@cca.cz
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

We have recently installed DHCP-2.0-5 via RPM on a Linux Red Hat server 
using version 2.2.16.
This server uses a fddi network card.
We have a transferred the dhcpd.conf file from the current DHCPD server 
(this uses eth0).

When we start the deamon on the new DHCPD server, it appears to start ok, 
but when we try to log on using this server
the PC cannot find the DHCPD Server, If we reconfigure the server to use 
eth0 it works ok.

Does anyone know how to get the server to function using fddi or where I 
can find out what I need to do?


Thanks

Tony



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-v4@bucknell.edu  Fri Oct 20 09:20:40 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 JAA09352
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 09:20:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KDJdb20164;
	Fri, 20 Oct 2000 09:19:39 -0400 (EDT)
Received: from quadntweb.quadritek.com ([198.200.138.211])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KDJQb06306
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 09:19:26 -0400 (EDT)
Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35)
          with SMTP id com; Fri, 20 Oct 2000 09:08:31 -0400
From: "A. Gregory Rabil" <grabil@lucent.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: <annd@Exchange.Microsoft.com>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed Standard
Date: Fri, 20 Oct 2000 09:19:36 -0400
Message-ID: <00ec01c03a98$6538dfc0$fe8ac8c6@quadritek.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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <93E299DA8B7DD411904300D0B7D4834305CD49@NS-EXCHANGE-SE>
Reply-To: grabil@lucent.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Jerome,
Of course I understand that Microsoft's implementation long predated the
User Class as Proposed Standard.  My question goes more toward the fact
that although MS may update future clients, server vendors will likely
have to deal with W2K clients for quite some time anyway.  It seems that
it would have been prudent to select a new option number for the new
format, just to ease the transition, then phase out 77 and use it for
something else.

My $0.02,
Greg

-----Original Message-----
From: Jerome Privat [mailto:jerome.privat@northstream.se]
Sent: Friday, October 20, 2000 3:02 AM
To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
Cc: 'annd@Exchange.Microsoft.com'
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Greg,

Implementation for existing Microsoft 2000 clients was written well before
the User Class was accepted as Proposed Standard (which just happenned now).
So it is normal it does not support what is in the spec now (the same is
true for other pre-standard implementations).

That being said, the syntax in the draft was discussed with people from
Microsoft (Ann Demirtjis at the time, who co-authored the draft). So I would
expect next versions of MS clients to adhere to the spec.

Jerome

Jerome Privat
Northstream AB

-----Original Message-----
From: grabil@lucent.com [mailto:grabil@lucent.com]
Sent: Thursday, October 19, 2000 6:30 PM
To: dhcp-v4@bucknell.edu
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----
From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
Behalf Of A. Gregory Rabil
Sent: Wednesday, October 11, 2000 6:09 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.




From owner-dhcp-v4@bucknell.edu  Fri Oct 20 10:58: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 KAA28286
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 10:58:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KEtBb20739;
	Fri, 20 Oct 2000 10:55:11 -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 e9KEt9b21457
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 10:55:09 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2TVT>; Fri, 20 Oct 2000 10:54:54 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607134@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	tandard
Date: Fri, 20 Oct 2000 10:54:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

While using a new option number is certainly a solution, it likely means
we'll have to keep the old one around forever.

As it should likely be fairly easy for a server to detect the difference,
perhaps that needs to be described in the draft/RFC ... I assume that
Microsoft's implementation is just to send the user class string in the
option. As this is likely to be ASCII, it should be easy for a server to
look at the received option and detect a 'problem' if the first class length
is greater than the option length (as that should not be possible). In that
case, it could assume that it is an old Microsoft client and use that option
format? Or, it would need to drop that option OR the entire packet as being
mal-formed.

- Bernie Volz

-----Original Message-----
From: A. Gregory Rabil [mailto:grabil@lucent.com]
Sent: Friday, October 20, 2000 9:20 AM
To: DHCPv4 discussion list
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Jerome,
Of course I understand that Microsoft's implementation long predated the
User Class as Proposed Standard.  My question goes more toward the fact
that although MS may update future clients, server vendors will likely
have to deal with W2K clients for quite some time anyway.  It seems that
it would have been prudent to select a new option number for the new
format, just to ease the transition, then phase out 77 and use it for
something else.

My $0.02,
Greg

-----Original Message-----
From: Jerome Privat [mailto:jerome.privat@northstream.se]
Sent: Friday, October 20, 2000 3:02 AM
To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
Cc: 'annd@Exchange.Microsoft.com'
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Greg,

Implementation for existing Microsoft 2000 clients was written well before
the User Class was accepted as Proposed Standard (which just happenned now).
So it is normal it does not support what is in the spec now (the same is
true for other pre-standard implementations).

That being said, the syntax in the draft was discussed with people from
Microsoft (Ann Demirtjis at the time, who co-authored the draft). So I would
expect next versions of MS clients to adhere to the spec.

Jerome

Jerome Privat
Northstream AB

-----Original Message-----
From: grabil@lucent.com [mailto:grabil@lucent.com]
Sent: Thursday, October 19, 2000 6:30 PM
To: dhcp-v4@bucknell.edu
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----
From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
Behalf Of A. Gregory Rabil
Sent: Wednesday, October 11, 2000 6:09 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 11:06: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 LAA29402
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 11:06:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KF3qb24809;
	Fri, 20 Oct 2000 11:03:52 -0400 (EDT)
Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KF36b10878
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 11:03:07 -0400 (EDT)
Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21)
	id <471G2LLG>; Fri, 20 Oct 2000 08:02:42 -0700
Message-ID: <716D440F8C29D311991100A0C92048748248FB@GIDGET.INCOGNITO.COM>
From: "Kostur, Andre" <Andre@incognito.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	 tandard
Date: Fri, 20 Oct 2000 08:02:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Andre@incognito.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Personally, I think Microsoft (and all vendors) should be required to
provide service packs/patches to their existing DHCP client stacks.  To
quote from every draft I've read:

"It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

When they included the User Class option in a production environment, they
knew that the option they were using could be subject to changes.

> -----Original Message-----
> From: Bernie Volz [mailto:Volz@ipworks.com]
> Sent: Friday, October 20, 2000 7:55 AM
> To: DHCPv4 discussion list
> Cc: annd@Exchange.Microsoft.com
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> S tandard
> 
> 
> While using a new option number is certainly a solution, it 
> likely means
> we'll have to keep the old one around forever.
> 
> As it should likely be fairly easy for a server to detect the 
> difference,
> perhaps that needs to be described in the draft/RFC ... I assume that
> Microsoft's implementation is just to send the user class 
> string in the
> option. As this is likely to be ASCII, it should be easy for 
> a server to
> look at the received option and detect a 'problem' if the 
> first class length
> is greater than the option length (as that should not be 
> possible). In that
> case, it could assume that it is an old Microsoft client and 
> use that option
> format? Or, it would need to drop that option OR the entire 
> packet as being
> mal-formed.
> 
> - Bernie Volz
> 
> -----Original Message-----
> From: A. Gregory Rabil [mailto:grabil@lucent.com]
> Sent: Friday, October 20, 2000 9:20 AM
> To: DHCPv4 discussion list
> Cc: annd@Exchange.Microsoft.com
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Jerome,
> Of course I understand that Microsoft's implementation long 
> predated the
> User Class as Proposed Standard.  My question goes more 
> toward the fact
> that although MS may update future clients, server vendors will likely
> have to deal with W2K clients for quite some time anyway.  It 
> seems that
> it would have been prudent to select a new option number for the new
> format, just to ease the transition, then phase out 77 and use it for
> something else.
> 
> My $0.02,
> Greg
> 
> -----Original Message-----
> From: Jerome Privat [mailto:jerome.privat@northstream.se]
> Sent: Friday, October 20, 2000 3:02 AM
> To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
> Cc: 'annd@Exchange.Microsoft.com'
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Greg,
> 
> Implementation for existing Microsoft 2000 clients was 
> written well before
> the User Class was accepted as Proposed Standard (which just 
> happenned now).
> So it is normal it does not support what is in the spec now 
> (the same is
> true for other pre-standard implementations).
> 
> That being said, the syntax in the draft was discussed with 
> people from
> Microsoft (Ann Demirtjis at the time, who co-authored the 
> draft). So I would
> expect next versions of MS clients to adhere to the spec.
> 
> Jerome
> 
> Jerome Privat
> Northstream AB
> 
> -----Original Message-----
> From: grabil@lucent.com [mailto:grabil@lucent.com]
> Sent: Thursday, October 19, 2000 6:30 PM
> To: dhcp-v4@bucknell.edu
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> I apologize for the repost, but I hear crickets... anyone 
> care to comment?
> 
> Greg
> 
> -----Original Message-----
> From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
> Behalf Of A. Gregory Rabil
> Sent: Wednesday, October 11, 2000 6:09 PM
> To: DHCPv4 discussion list
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Has anyone given thought to the implications involved with 
> the existing
> Microsoft Windows 2000 DHCP clients that use this option?  
> Specifically, MS
> W2K clients use option 77, but they don't have/support the 
> multiple user
> classes as defined in this latest revision.  This seems like 
> a very big
> interoperability problem for servers that are using this 
> option with W2K
> clients today.
> 
> Greg
> 
> -----Original Message-----
> From: scoya@cnri.reston.va.us 
> [mailto:scoya@cnri.reston.va.us]On Behalf
> Of The IESG
> Sent: Tuesday, October 10, 2000 2:16 PM
> To: IETF-Announce: ;
> Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
> Subject: Protocol Action: The User Class Option for DHCP to Proposed
> Standard
> 
> 
> 
> 
> The IESG has approved the Internet-Draft 'The User Class Option for
> DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
> document is the product of the Dynamic Host Configuration Working
> Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.
> 
> 
> Technical Summary
> 
> This document defines a DHCP option that is used by a DHCP client to
> optionally identify the type or category of user or applications it
> represents. The information contained in this option is an opaque
> field that represents the user class of which the client is a member.
> Based on this class, a DHCP server selects the appropriate address
> pool to assign an address to the client and the appropriate
> configuration parameters.  This option should be configurable by a
> user.
> 
> Working Group Summary
> 
> There was strong support for this option within the WG, and no issues
> were raised during the IETF Last Call.
> 
> Protocol Quality
> 
> This document has been reviewed for the IESG by Thomas Narten.
> 



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 11:27: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 LAA02133
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 11:27:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KFQlb18159;
	Fri, 20 Oct 2000 11:26:47 -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 e9KFQfb04534
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 11:26:41 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2TXJ>; Fri, 20 Oct 2000 11:26:26 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607135@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	 tandard
Date: Fri, 20 Oct 2000 11:26:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

While that would be nice, does it mean everyone will install it? No.

I think for server implementors, perhaps the best rule to follow is ignore
the option if it is malformed (and understand that it could easily be
malformed because of these older implementations). That might be the
quickest way to resolve the problem and get the draft out.

-----Original Message-----
From: Kostur, Andre [mailto:Andre@INCOGNITO.COM]
Sent: Friday, October 20, 2000 11:03 AM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
S tandard


Personally, I think Microsoft (and all vendors) should be required to
provide service packs/patches to their existing DHCP client stacks.  To
quote from every draft I've read:

"It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

When they included the User Class option in a production environment, they
knew that the option they were using could be subject to changes.

> -----Original Message-----
> From: Bernie Volz [mailto:Volz@ipworks.com]
> Sent: Friday, October 20, 2000 7:55 AM
> To: DHCPv4 discussion list
> Cc: annd@Exchange.Microsoft.com
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> S tandard
> 
> 
> While using a new option number is certainly a solution, it 
> likely means
> we'll have to keep the old one around forever.
> 
> As it should likely be fairly easy for a server to detect the 
> difference,
> perhaps that needs to be described in the draft/RFC ... I assume that
> Microsoft's implementation is just to send the user class 
> string in the
> option. As this is likely to be ASCII, it should be easy for 
> a server to
> look at the received option and detect a 'problem' if the 
> first class length
> is greater than the option length (as that should not be 
> possible). In that
> case, it could assume that it is an old Microsoft client and 
> use that option
> format? Or, it would need to drop that option OR the entire 
> packet as being
> mal-formed.
> 
> - Bernie Volz
> 
> -----Original Message-----
> From: A. Gregory Rabil [mailto:grabil@lucent.com]
> Sent: Friday, October 20, 2000 9:20 AM
> To: DHCPv4 discussion list
> Cc: annd@Exchange.Microsoft.com
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Jerome,
> Of course I understand that Microsoft's implementation long 
> predated the
> User Class as Proposed Standard.  My question goes more 
> toward the fact
> that although MS may update future clients, server vendors will likely
> have to deal with W2K clients for quite some time anyway.  It 
> seems that
> it would have been prudent to select a new option number for the new
> format, just to ease the transition, then phase out 77 and use it for
> something else.
> 
> My $0.02,
> Greg
> 
> -----Original Message-----
> From: Jerome Privat [mailto:jerome.privat@northstream.se]
> Sent: Friday, October 20, 2000 3:02 AM
> To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
> Cc: 'annd@Exchange.Microsoft.com'
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Greg,
> 
> Implementation for existing Microsoft 2000 clients was 
> written well before
> the User Class was accepted as Proposed Standard (which just 
> happenned now).
> So it is normal it does not support what is in the spec now 
> (the same is
> true for other pre-standard implementations).
> 
> That being said, the syntax in the draft was discussed with 
> people from
> Microsoft (Ann Demirtjis at the time, who co-authored the 
> draft). So I would
> expect next versions of MS clients to adhere to the spec.
> 
> Jerome
> 
> Jerome Privat
> Northstream AB
> 
> -----Original Message-----
> From: grabil@lucent.com [mailto:grabil@lucent.com]
> Sent: Thursday, October 19, 2000 6:30 PM
> To: dhcp-v4@bucknell.edu
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> I apologize for the repost, but I hear crickets... anyone 
> care to comment?
> 
> Greg
> 
> -----Original Message-----
> From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
> Behalf Of A. Gregory Rabil
> Sent: Wednesday, October 11, 2000 6:09 PM
> To: DHCPv4 discussion list
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Has anyone given thought to the implications involved with 
> the existing
> Microsoft Windows 2000 DHCP clients that use this option?  
> Specifically, MS
> W2K clients use option 77, but they don't have/support the 
> multiple user
> classes as defined in this latest revision.  This seems like 
> a very big
> interoperability problem for servers that are using this 
> option with W2K
> clients today.
> 
> Greg
> 
> -----Original Message-----
> From: scoya@cnri.reston.va.us 
> [mailto:scoya@cnri.reston.va.us]On Behalf
> Of The IESG
> Sent: Tuesday, October 10, 2000 2:16 PM
> To: IETF-Announce: ;
> Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
> Subject: Protocol Action: The User Class Option for DHCP to Proposed
> Standard
> 
> 
> 
> 
> The IESG has approved the Internet-Draft 'The User Class Option for
> DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
> document is the product of the Dynamic Host Configuration Working
> Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.
> 
> 
> Technical Summary
> 
> This document defines a DHCP option that is used by a DHCP client to
> optionally identify the type or category of user or applications it
> represents. The information contained in this option is an opaque
> field that represents the user class of which the client is a member.
> Based on this class, a DHCP server selects the appropriate address
> pool to assign an address to the client and the appropriate
> configuration parameters.  This option should be configurable by a
> user.
> 
> Working Group Summary
> 
> There was strong support for this option within the WG, and no issues
> were raised during the IETF Last Call.
> 
> Protocol Quality
> 
> This document has been reviewed for the IESG by Thomas Narten.
> 



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 11:44: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 LAA04152
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 11:44:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KFf7b21721;
	Fri, 20 Oct 2000 11:41:07 -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 e9KFdkb02722
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 11:39:46 -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 LAA25924; Fri, 20 Oct 2000 11:39:27 -0400 (EDT)
Message-Id: <4.2.0.58.20001020112426.01c36710@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 20 Oct 2000 11:40:16 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: RE: Protocol Action: The User Class Option for DHCP to
  Proposed S tandard
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>, kkinnear@cisco.com
In-Reply-To: <716D440F8C29D311991100A0C92048748248FB@GIDGET.INCOGNITO.CO
 M>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: kkinnear@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 08:02 AM 10/20/00 -0700, Kostur, Andre wrote:
>Personally, I think Microsoft (and all vendors) should be required to
>provide service packs/patches to their existing DHCP client stacks.  To
>quote from every draft I've read:
>
>"It is inappropriate to use Internet- Drafts
>    as reference material or to cite them other than as "work in
>    progress."
>
>When they included the User Class option in a production environment, they
>knew that the option they were using could be subject to changes.

         Even if vendors chose to provide service packs/patches
         for DHCP clients, many customers will not apply them.
         And as a vendor of DHCP servers, I'm interested in making
         a DHCP server that works correctly whether or not an
         individual user has applied a service pack or not.

         I strongly believe that we need a way that we can tell in
         an unambiguous way if this is an old-style or
         correct-style userclass option.  If we can get that from
         the current userclass definition, then we are fine (more
         or less, though it would be nice if it were simple to
         understand).  If we can't, then I think we need a new
         option number or a new definition of "correct-sytle"
         userclass.  If we do a new option number, the old one
         will be around for years and years (not a value
         judgement, just a fact).

         Bernie's algorithm seems to work fine as long as the
         first user-class class length doesn't happen to be in the
         range of printable ascii.  Ignoring punctuation marks,
         the ascii space is 32 decimal, and numeric 0 is 48.  Both
         of these would seem to be reasonable values for a
         userclass class length, wouldn't they?  Or am I missing
         something.

         Cheers -- Kim




> > -----Original Message-----
> > From: Bernie Volz [mailto:Volz@ipworks.com]
> > Sent: Friday, October 20, 2000 7:55 AM
> > To: DHCPv4 discussion list
> > Cc: annd@Exchange.Microsoft.com
> > Subject: RE: Protocol Action: The User Class Option for DHCP 
> > to Proposed
> > S tandard
> > 
> > 
> > While using a new option number is certainly a solution, it 
> > likely means
> > we'll have to keep the old one around forever.
> > 
> > As it should likely be fairly easy for a server to detect the 
> > difference,
> > perhaps that needs to be described in the draft/RFC ... I assume that
> > Microsoft's implementation is just to send the user class 
> > string in the
> > option. As this is likely to be ASCII, it should be easy for 
> > a server to
> > look at the received option and detect a 'problem' if the 
> > first class length
> > is greater than the option length (as that should not be 
> > possible). In that
> > case, it could assume that it is an old Microsoft client and 
> > use that option
> > format? Or, it would need to drop that option OR the entire 
> > packet as being
> > mal-formed.
> > 
> > - Bernie Volz
> > 
> > -----Original Message-----
> > From: A. Gregory Rabil [mailto:grabil@lucent.com]
> > Sent: Friday, October 20, 2000 9:20 AM
> > To: DHCPv4 discussion list
> > Cc: annd@Exchange.Microsoft.com
> > Subject: RE: Protocol Action: The User Class Option for DHCP 
> > to Proposed
> > Standard
> > 
> > 
> > Jerome,
> > Of course I understand that Microsoft's implementation long 
> > predated the
> > User Class as Proposed Standard.  My question goes more 
> > toward the fact
> > that although MS may update future clients, server vendors will likely
> > have to deal with W2K clients for quite some time anyway.  It 
> > seems that
> > it would have been prudent to select a new option number for the new
> > format, just to ease the transition, then phase out 77 and use it for
> > something else.
> > 
> > My $0.02,
> > Greg
> > 
> > -----Original Message-----
> > From: Jerome Privat [mailto:jerome.privat@northstream.se]
> > Sent: Friday, October 20, 2000 3:02 AM
> > To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
> > Cc: 'annd@Exchange.Microsoft.com'
> > Subject: RE: Protocol Action: The User Class Option for DHCP 
> > to Proposed
> > Standard
> > 
> > 
> > Greg,
> > 
> > Implementation for existing Microsoft 2000 clients was 
> > written well before
> > the User Class was accepted as Proposed Standard (which just 
> > happenned now).
> > So it is normal it does not support what is in the spec now 
> > (the same is
> > true for other pre-standard implementations).
> > 
> > That being said, the syntax in the draft was discussed with 
> > people from
> > Microsoft (Ann Demirtjis at the time, who co-authored the 
> > draft). So I would
> > expect next versions of MS clients to adhere to the spec.
> > 
> > Jerome
> > 
> > Jerome Privat
> > Northstream AB
> > 
> > -----Original Message-----
> > From: grabil@lucent.com [mailto:grabil@lucent.com]
> > Sent: Thursday, October 19, 2000 6:30 PM
> > To: dhcp-v4@bucknell.edu
> > Subject: RE: Protocol Action: The User Class Option for DHCP 
> > to Proposed
> > Standard
> > 
> > 
> > I apologize for the repost, but I hear crickets... anyone 
> > care to comment?
> > 
> > Greg
> > 
> > -----Original Message-----
> > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
> > Behalf Of A. Gregory Rabil
> > Sent: Wednesday, October 11, 2000 6:09 PM
> > To: DHCPv4 discussion list
> > Subject: RE: Protocol Action: The User Class Option for DHCP 
> > to Proposed
> > Standard
> > 
> > 
> > Has anyone given thought to the implications involved with 
> > the existing
> > Microsoft Windows 2000 DHCP clients that use this option?  
> > Specifically, MS
> > W2K clients use option 77, but they don't have/support the 
> > multiple user
> > classes as defined in this latest revision.  This seems like 
> > a very big
> > interoperability problem for servers that are using this 
> > option with W2K
> > clients today.
> > 
> > Greg
> > 
> > -----Original Message-----
> > From: scoya@cnri.reston.va.us 
> > [mailto:scoya@cnri.reston.va.us]On Behalf
> > Of The IESG
> > Sent: Tuesday, October 10, 2000 2:16 PM
> > To: IETF-Announce: ;
> > Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
> > Subject: Protocol Action: The User Class Option for DHCP to Proposed
> > Standard
> > 
> > 
> > 
> > 
> > The IESG has approved the Internet-Draft 'The User Class Option for
> > DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
> > document is the product of the Dynamic Host Configuration Working
> > Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.
> > 
> > 
> > Technical Summary
> > 
> > This document defines a DHCP option that is used by a DHCP client to
> > optionally identify the type or category of user or applications it
> > represents. The information contained in this option is an opaque
> > field that represents the user class of which the client is a member.
> > Based on this class, a DHCP server selects the appropriate address
> > pool to assign an address to the client and the appropriate
> > configuration parameters.  This option should be configurable by a
> > user.
> > 
> > Working Group Summary
> > 
> > There was strong support for this option within the WG, and no issues
> > were raised during the IETF Last Call.
> > 
> > Protocol Quality
> > 
> > This document has been reviewed for the IESG by Thomas Narten.
> > 



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 11:46: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 LAA04402
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 11:46:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KFjQb17376;
	Fri, 20 Oct 2000 11:45:26 -0400 (EDT)
Received: from quadntweb.quadritek.com ([198.200.138.211])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KFjGb07513
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 11:45:16 -0400 (EDT)
Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35)
          with SMTP id com; Fri, 20 Oct 2000 11:34:22 -0400
From: "A. Gregory Rabil" <grabil@lucent.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: <annd@Exchange.Microsoft.com>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed Standard
Date: Fri, 20 Oct 2000 11:45:28 -0400
Message-ID: <00f801c03aac$c6190bd0$fe8ac8c6@quadritek.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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607134@lespaul.process.com>
Reply-To: grabil@lucent.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Unfortunately, I don't think it is possible to detect a 'problem'.  For
example, assume a User Class of the following:

!SomeThirtyThreeCharacterUserClass

Note that the '!' is a decimal 33.  Therefore, if the option code 77 was
followed by a length byte of decimal 34, then the above ascii string
(including the prefixed '!').  In this case, this is valid for both
formats of the UserClass option.  It appears impossible to determine if
the User Class is "SomeThirtyThreeCharacterUserClass" or
"!SomeThirtyThreeCharacterUserClass".

Regards,
Greg

-----Original Message-----
From: Bernie Volz [mailto:Volz@ipworks.com]
Sent: Friday, October 20, 2000 10:55 AM
To: 'grabil@lucent.com'; DHCPv4 discussion list
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


While using a new option number is certainly a solution, it likely means
we'll have to keep the old one around forever.

As it should likely be fairly easy for a server to detect the difference,
perhaps that needs to be described in the draft/RFC ... I assume that
Microsoft's implementation is just to send the user class string in the
option. As this is likely to be ASCII, it should be easy for a server to
look at the received option and detect a 'problem' if the first class length
is greater than the option length (as that should not be possible). In that
case, it could assume that it is an old Microsoft client and use that option
format? Or, it would need to drop that option OR the entire packet as being
mal-formed.

- Bernie Volz

-----Original Message-----
From: A. Gregory Rabil [mailto:grabil@lucent.com]
Sent: Friday, October 20, 2000 9:20 AM
To: DHCPv4 discussion list
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Jerome,
Of course I understand that Microsoft's implementation long predated the
User Class as Proposed Standard.  My question goes more toward the fact
that although MS may update future clients, server vendors will likely
have to deal with W2K clients for quite some time anyway.  It seems that
it would have been prudent to select a new option number for the new
format, just to ease the transition, then phase out 77 and use it for
something else.

My $0.02,
Greg

-----Original Message-----
From: Jerome Privat [mailto:jerome.privat@northstream.se]
Sent: Friday, October 20, 2000 3:02 AM
To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
Cc: 'annd@Exchange.Microsoft.com'
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Greg,

Implementation for existing Microsoft 2000 clients was written well before
the User Class was accepted as Proposed Standard (which just happenned now).
So it is normal it does not support what is in the spec now (the same is
true for other pre-standard implementations).

That being said, the syntax in the draft was discussed with people from
Microsoft (Ann Demirtjis at the time, who co-authored the draft). So I would
expect next versions of MS clients to adhere to the spec.

Jerome

Jerome Privat
Northstream AB

-----Original Message-----
From: grabil@lucent.com [mailto:grabil@lucent.com]
Sent: Thursday, October 19, 2000 6:30 PM
To: dhcp-v4@bucknell.edu
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----
From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
Behalf Of A. Gregory Rabil
Sent: Wednesday, October 11, 2000 6:09 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 12:00:15 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 MAA06285
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 12:00:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KFxFb21768;
	Fri, 20 Oct 2000 11:59:15 -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 e9KFx5b24888
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 11:59:05 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <4MYY2TZ8>; Fri, 20 Oct 2000 11:58:49 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607138@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	tandard
Date: Fri, 20 Oct 2000 11:58: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: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Yes, the technique I suggested won't work for all cases. But I think it is
relatively safe as (1) I would suspect all alpha characters are more typical
and (2) shorter class names will be much more common.

Perhaps Microsoft can provide some input here as to what classes they
recommend or support - perhaps the configuration utilities only support a
limited character set and an upper length (<32).

It certainly is, IMHO, a better solution than assigning another option
number given that the available option space is rather small.

If you wanted to assure you have compatibility, perhaps a solution is to
have the new format insert a 0 byte as the first class string. Then, the
issues are we waste a byte and some small processing time and the only
reserved character for older style Microsoft implementations to avoid is the
0 (null) character.

- Bernie

-----Original Message-----
From: A. Gregory Rabil [mailto:grabil@lucent.com]
Sent: Friday, October 20, 2000 11:45 AM
To: DHCPv4 discussion list
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Unfortunately, I don't think it is possible to detect a 'problem'.  For
example, assume a User Class of the following:

!SomeThirtyThreeCharacterUserClass

Note that the '!' is a decimal 33.  Therefore, if the option code 77 was
followed by a length byte of decimal 34, then the above ascii string
(including the prefixed '!').  In this case, this is valid for both
formats of the UserClass option.  It appears impossible to determine if
the User Class is "SomeThirtyThreeCharacterUserClass" or
"!SomeThirtyThreeCharacterUserClass".

Regards,
Greg

-----Original Message-----
From: Bernie Volz [mailto:Volz@ipworks.com]
Sent: Friday, October 20, 2000 10:55 AM
To: 'grabil@lucent.com'; DHCPv4 discussion list
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


While using a new option number is certainly a solution, it likely means
we'll have to keep the old one around forever.

As it should likely be fairly easy for a server to detect the difference,
perhaps that needs to be described in the draft/RFC ... I assume that
Microsoft's implementation is just to send the user class string in the
option. As this is likely to be ASCII, it should be easy for a server to
look at the received option and detect a 'problem' if the first class length
is greater than the option length (as that should not be possible). In that
case, it could assume that it is an old Microsoft client and use that option
format? Or, it would need to drop that option OR the entire packet as being
mal-formed.

- Bernie Volz

-----Original Message-----
From: A. Gregory Rabil [mailto:grabil@lucent.com]
Sent: Friday, October 20, 2000 9:20 AM
To: DHCPv4 discussion list
Cc: annd@Exchange.Microsoft.com
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Jerome,
Of course I understand that Microsoft's implementation long predated the
User Class as Proposed Standard.  My question goes more toward the fact
that although MS may update future clients, server vendors will likely
have to deal with W2K clients for quite some time anyway.  It seems that
it would have been prudent to select a new option number for the new
format, just to ease the transition, then phase out 77 and use it for
something else.

My $0.02,
Greg

-----Original Message-----
From: Jerome Privat [mailto:jerome.privat@northstream.se]
Sent: Friday, October 20, 2000 3:02 AM
To: 'grabil@lucent.com'; dhcp-v4@bucknell.edu
Cc: 'annd@Exchange.Microsoft.com'
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Greg,

Implementation for existing Microsoft 2000 clients was written well before
the User Class was accepted as Proposed Standard (which just happenned now).
So it is normal it does not support what is in the spec now (the same is
true for other pre-standard implementations).

That being said, the syntax in the draft was discussed with people from
Microsoft (Ann Demirtjis at the time, who co-authored the draft). So I would
expect next versions of MS clients to adhere to the spec.

Jerome

Jerome Privat
Northstream AB

-----Original Message-----
From: grabil@lucent.com [mailto:grabil@lucent.com]
Sent: Thursday, October 19, 2000 6:30 PM
To: dhcp-v4@bucknell.edu
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----
From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On
Behalf Of A. Gregory Rabil
Sent: Wednesday, October 11, 2000 6:09 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard


Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; dhcp-v4@bucknell.edu
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard




The IESG has approved the Internet-Draft 'The User Class Option for
DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
document is the product of the Dynamic Host Configuration Working
Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.


Technical Summary

This document defines a DHCP option that is used by a DHCP client to
optionally identify the type or category of user or applications it
represents. The information contained in this option is an opaque
field that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.  This option should be configurable by a
user.

Working Group Summary

There was strong support for this option within the WG, and no issues
were raised during the IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 12:13: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 MAA08195
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 12:13:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KGCwb24771;
	Fri, 20 Oct 2000 12:12:58 -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 e9KGCfb13634
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 12:12:41 -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 MAA29988; Fri, 20 Oct 2000 12:12:22 -0400 (EDT)
Message-Id: <4.2.0.58.20001020120943.00a2faf0@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 20 Oct 2000 12:13:13 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: RE: Protocol Action: The User Class Option for DHCP to
  Proposed S tandard
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>, kkinnear@cisco.com
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8603607138@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: kkinnear@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:58 AM 10/20/00 -0400, Bernie Volz wrote:
>[...]
>
>If you wanted to assure you have compatibility, perhaps a solution is to
>have the new format insert a 0 byte as the first class string. Then, the
>issues are we waste a byte and some small processing time and the only
>reserved character for older style Microsoft implementations to avoid is the
>0 (null) character.


         I rather like this, though it always costs a byte.
         It *does* seem better than wasting another option number,
         or putting our heads in the sand and ignoring the problem.

         Of course, from a purist perspective, it is totally
         unnecessary and wasteful.  Unfortunately, neither I
         nor my customers live in a purist world.

         Cheers -- Kim



>- Bernie
>
>-----Original Message-----
>From: A. Gregory Rabil [mailto:grabil@lucent.com]
>Sent: Friday, October 20, 2000 11:45 AM
>To: DHCPv4 discussion list
>Cc: annd@Exchange.Microsoft.com
>Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
>Standard
>
>
>Unfortunately, I don't think it is possible to detect a 'problem'.  For
>example, assume a User Class of the following:
>
>!SomeThirtyThreeCharacterUserClass
>
>Note that the '!' is a decimal 33.  Therefore, if the option code 77 was
>followed by a length byte of decimal 34, then the above ascii string
>(including the prefixed '!').  In this case, this is valid for both
>formats of the UserClass option.  It appears impossible to determine if
>the User Class is "SomeThirtyThreeCharacterUserClass" or
>"!SomeThirtyThreeCharacterUserClass".
>
>Regards,
>Greg
  



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-v4@bucknell.edu  Fri Oct 20 12:34: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 MAA10898
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 12:34:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KGV6b23717;
	Fri, 20 Oct 2000 12:31:06 -0400 (EDT)
Received: from neimail.networkengines.com (wks7.networkengines.com [64.55.6.7] (may be forged))
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9KGUvb08798
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 12:30:57 -0400 (EDT)
Received: by neimail.networkengines.com with Internet Mail Service (5.5.2650.21)
	id <V2614L6V>; Fri, 20 Oct 2000 12:28:39 -0400
Message-ID: <8D18C4F9CBA1D311900F00A0C990C97FD862C9@neimail.networkengines.com>
From: Steve Gonczi <Steve.Gonczi@networkengines.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	 tandard
Date: Fri, 20 Oct 2000 12:28:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Steve.Gonczi@networkengines.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I rather like Bernie's solution.

The reserved character does not have to be zero, it could be any
character reserved for this purpose.

It would be nice to hear from MS to see if this would work for them.

/sG

>If you wanted to assure you have compatibility, perhaps a solution is to
>have the new format insert a 0 byte as the first class string. 



From owner-dhcp-v4@bucknell.edu  Fri Oct 20 19:14: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 TAA02905
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 20 Oct 2000 19:14:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9KNAnb28513;
	Fri, 20 Oct 2000 19:10:49 -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 e9KNAZb14404
	for <dhcp-v4@bucknell.edu>; Fri, 20 Oct 2000 19:10:35 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VJWD9QZ3>; Fri, 20 Oct 2000 19:10:18 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE860360713D@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S
	 tandard
Date: Fri, 20 Oct 2000 19:10:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

There is a benefit in using 0. From the draft:

	The value in UC_Len_i does not include the length field itself and
	MUST be non-zero.

So, 0 is not technically a legal class length for the option but would be in
this case as a filler (ie, no class specified).

We could either allow it as a length (meaning no class) or just REQUIRE it
as the first value if the new option format is in use.

Perhaps even a better approach ... if we assume that the class names (as
Microsoft has it implemented today) may NOT begin with a ASCII character
0..31, then we could even only require the special 0 byte if the length of
the first class in the class list is >31. That saves the extra byte and
likely means it would be extremely rare anyway.

- Bernie

-----Original Message-----
From: Steve Gonczi [mailto:Steve.Gonczi@networkengines.com]
Sent: Friday, October 20, 2000 12:29 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
S tandard


I rather like Bernie's solution.

The reserved character does not have to be zero, it could be any
character reserved for this purpose.

It would be nice to hear from MS to see if this would work for them.

/sG

>If you wanted to assure you have compatibility, perhaps a solution is to
>have the new format insert a 0 byte as the first class string. 



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-v4@bucknell.edu  Mon Oct 23 03:31: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 DAA29492
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 23 Oct 2000 03:31:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9N7Rmb30165;
	Mon, 23 Oct 2000 03:27:48 -0400 (EDT)
Received: from bofur.cca.cz (bofur.cca.cz [194.212.149.10])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9N7Rhb27924
	for <DHCP-V4@BUCKNELL.EDU>; Mon, 23 Oct 2000 03:27:44 -0400 (EDT)
Received: from pc023.cca.cz (pc023.cca.cz [194.212.149.72])
	by bofur.cca.cz (8.11.0/8.11.0) with ESMTP id e9N7S5e07750
	for <DHCP-V4@BUCKNELL.EDU>; Mon, 23 Oct 2000 09:28:07 +0200
From: Antonin.Novak@cca.cz
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Problem running DHCPD over FDDI
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF80A5B7C3.EBAF3ECF-ONC1256981.0028C5F6@cca.cz>
Date: Mon, 23 Oct 2000 09:27:22 +0200
X-MIMETrack: Serialize by Notes Client on
 =?iso-8859-2?q?Anton=EDn_Ch_Novak=2FPlzen=2FCCA=28Release_5=2E0=2E3_=28?=
 =?us-ascii?q?Intl?= =?us-ascii?q?=29|?= =?us-ascii?q?21?= March 2000) at
 23.10.2000 09:27:23,
	Serialize complete at 23.10.2000 09:27:23
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0028F223C1256981_="
Reply-To: Antonin.Novak@cca.cz
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This is a multipart message in MIME format.
--=_alternative 0028F223C1256981_=
Content-Type: text/plain; charset="us-ascii"

We have recently installed DHCP-2.0-5 via RPM on a Linux Red Hat server 
using version 2.2.16.
This server uses a fddi network card.
We have a transferred the dhcpd.conf file from the current DHCPD server 
(this uses eth0).

When we start the deamon on the new DHCPD server, it appears to start ok, 
but when we try to log on using this server
the PC cannot find the DHCPD Server, If we reconfigure the server to use 
eth0 it works ok.

Does anyone know how to get the server to function using fddi or where I 
can find out what I need to do?


Thanks

Tony
--=_alternative 0028F223C1256981_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">We have recently installed DHCP-2.0-5 via RPM on a Linux Red Hat server using version 2.2.16.</font>
<br><font size=2 face="sans-serif">This server uses a fddi network card.</font>
<br><font size=2 face="sans-serif">We have a transferred the dhcpd.conf file from the current DHCPD server &nbsp;(this uses eth0).</font>
<br>
<br><font size=2 face="sans-serif">When we start the deamon on the new DHCPD server, it appears to start ok, but when we try to log on using this server</font>
<br><font size=2 face="sans-serif">the PC cannot find the DHCPD Server, If we reconfigure the server to use eth0 it works ok.</font>
<br>
<br><font size=2 face="sans-serif">Does anyone know how to get the server to function using fddi or where I can find out what I need to do?</font>
<br>
<br>
<br><font size=2 face="sans-serif">Thanks</font>
<br>
<br><font size=2 face="sans-serif">Tony</font>
--=_alternative 0028F223C1256981_=--



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-v4@bucknell.edu  Mon Oct 23 15:01: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 PAA05830
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 23 Oct 2000 15:01:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NIuHb11824;
	Mon, 23 Oct 2000 14:56:17 -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 e9NIuBb31414
	for <dhcp-v4@bucknell.edu>; Mon, 23 Oct 2000 14:56:11 -0400 (EDT)
Received: from internaut.com (uucp@localhost)
	by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id LAA30967
	for bucknell.edu!dhcp-v4; Mon, 23 Oct 2000 11:56:10 -0700 (PDT)
Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0)
	id AA12740; Mon, 23 Oct 00 11:36:04 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: draft-aboba-dhc-domsearch-00.txt
Date: Mon, 23 Oct 2000 11:54:35 -0700
Message-Id: <OJEJKOMOEAKLMOILFCPJEEPKDHAA.aboba@internaut.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0043_01C03CE8.0372D370"
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OF80A5B7C3.EBAF3ECF-ONC1256981.0028C5F6@cca.cz>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: aboba@internaut.com
Sender: owner-dhcp-v4@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_0043_01C03CE8.0372D370
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

draft-aboba-dhc-domsearch-00.txt has been posted to the IETF archive:
 http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-00.txt

Comments welcome. 



 


------=_NextPart_000_0043_01C03CE8.0372D370
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D397515218-23102000><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2>draft-aboba-dhc-domsearch-00.txt<SPAN=20
class=3D397515218-23102000>&nbsp;</SPAN>has been posted to the IETF =
archive<SPAN=20
class=3D397515218-23102000>:</SPAN></FONT></FONT></FONT></DIV>
<DIV>
<P><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D397515218-23102000>&nbsp;</SPAN><SPAN =
class=3D397515218-23102000><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-00.=
txt">http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-00.txt=
</A></SPAN></FONT></FONT></FONT></P>
<P><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D397515218-23102000>Comments welcome. =
</SPAN></FONT></FONT></FONT></P>
<P><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D397515218-23102000><FONT size=3D2>&nbsp;</P>
<P></FONT>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></P></DIV></BODY></HTM=
L>

------=_NextPart_000_0043_01C03CE8.0372D370--



From owner-dhcp-v4@bucknell.edu  Mon Oct 23 15:14: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 PAA08629
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 23 Oct 2000 15:14:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9NJBbb04591;
	Mon, 23 Oct 2000 15:11:37 -0400 (EDT)
Received: from styx.uwaterloo.ca (styx.uwaterloo.ca [129.97.40.10])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9NJB9b24102
	for <dhcp-v4@bucknell.edu>; Mon, 23 Oct 2000 15:11:09 -0400 (EDT)
Received: from localhost (bmukherj@localhost)
	by styx.uwaterloo.ca (8.9.3/8.9.3) with ESMTP id PAA30560
	for <dhcp-v4@bucknell.edu>; Mon, 23 Oct 2000 15:10:50 -0400
Date: Mon, 23 Oct 2000 15:10:50 -0400 (EDT)
From: Roop Mukherjee <bmukherj@styx.uwaterloo.ca>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: New Draft about using DHCP for roaming users. 
In-Reply-To: <OJEJKOMOEAKLMOILFCPJEEPKDHAA.aboba@internaut.com>
Message-ID: <Pine.LNX.4.04.10010231503050.30279-100000@styx.uwaterloo.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: bmukherj@styx.uwaterloo.ca
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Plrease find attached, the abstract of the draft and a url for the same. I
am seekign comments from the working group as well the mailing list in
general.

Thanks,
Roop Mukherjee

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Extensions to DHCP for Roaming Users
	Author(s)	: B. Mukherjee, B. Gage, Y. Liu, J. Melzer
	Filename	: draft-mukherjee-dhc-dhcproam-00.txt
	Pages		: 19
	Date		: 17-Oct-00
	
This draft proposes enhancements to DHCP so that it can be used to
securely provide dynamic configuration to roaming mobile hosts. The
problem has two major aspects: 1) adding extensible, inter-domain,
user and network authentication functionality to DHCP and 2) to
allow DHCP to function without relying on link layer specific
mechanisms. The first feature would allow authenticated and audited
visited network usage for roaming users while the second feature
would allow DHCP to be used in the new environments like the
wireless data networks. The authentication mechanism proposed here
interacts with existing public Authentication, Authorization, and
Accounting (AAA) mechanisms, thus enabling per customer
authentication authorization and accounting across multiple domains.
In addition, we propose a mechanism that enables the client to
authenticate the DHCP server that has provided it with configuration
parameters. We also describe a mechanism that allows DHCP to work
independent of link layer broadcasts and addressing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mukherjee-dhc-dhcproam-00.txt



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-v4@bucknell.edu  Tue Oct 24 14:07:42 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07995
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 24 Oct 2000 14:07:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9OI1hb00301;
	Tue, 24 Oct 2000 14:01: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 e9OI1cb05041
	for <dhcp-v4@bucknell.edu>; Tue, 24 Oct 2000 14:01:38 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VRHK08TD>; Tue, 24 Oct 2000 14:01:22 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8603607156@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Updated draft-ietf-dhc-loadb-03.txt
Date: Tue, 24 Oct 2000 14:01:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C03DE4.6B1AB888"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C03DE4.6B1AB888
Content-Type: text/plain;
	charset="iso-8859-1"

Folks:

I've just submitted an updated version draft-ietf-dhc-loadb (load
balancing). This update removes some normative references to other documents
as requested per the last-call:
	- References to the failover draft have been reworked. Also, the
option formats for failover have been removed. These should appear in the
failover draft as it will advance to RFC later.
	- References to the SSO draft were removed as this draft no longer
exists (it has expired).

Those are the significant changes.

 <<draft-ietf-dhc-loadb-03.txt>> 
- Bernie Volz
  IPWorks, Inc.

------_=_NextPart_000_01C03DE4.6B1AB888
Content-Type: text/plain;
	name="draft-ietf-dhc-loadb-03.txt"
Content-Disposition: attachment;
	filename="draft-ietf-dhc-loadb-03.txt"
Content-Transfer-Encoding: quoted-printable

Network Working group	DHC Load Balancing Algorithm	September 2000

Internet Draft					Bernie Volz
						IPWorks, Inc.

						Steve Gonczi
						Network Engines, Inc.

						Ted Lemon
						Internet Engines, Inc.

						Rob Stevens
						Join Systems, Inc.

September 2000					Expires March 2001

		DHC Load Balancing Algorithm
		<draft-ietf-dhc-loadb-03.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." The list of current
Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This draft proposes a method of algorithmic load balancing. It enables
multiple, cooperating servers to decide which one should service a
client, without exchanging any information beyond initial =
configuration.

The server selection is based on the servers hashing client MAC
addresses when multiple DHCP servers are available to service DHCP
clients. The proposed techique provides for efficient server selection
when multiple DHCP servers offer services on a network without =
requiring
any changes to existing DHCP clients. The same method is proposed to
select the target server of a forwarding agent such as a BOOTP relay.







Gonczi, et. al.          Expires March 2001                 [Page 1]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000

1.  Introduction

This protocol was originally devised to support a specific load
balancing optimization of the DHCP Failover Protocol [FAILOVR]. The
authors later realized that it could be used to optimize the behavior =
of
cooperating DHCP servers and the BOOTP relay agents that forward =
packets
to them. The proposal makes it possible to set up each participating
server to accept a preconfigured (approximate) percentage of the client
load. This is done using a deterministic hashing algorithm, that could
easily be applied to other protocols having similar characteristics.

2. Terminology

This section discusses both the generic requirements terminology common
to many IETF protocol specifications, and also terminology introduced =
by
this document.

2.1.  Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].

2.2. Load Balancing Terminology

This document introduces the following terms:

Service Delay, SD
   A load balancing parameter, allowing delayed service of a client by =
a
   server participating in the load-balancing scheme, instead of
   ignoring the client.

Hash Bucket Assignments, HBA
   A configuration directive that assigns a set of hash bucket values =
to
   a server participating in the load-balancing scheme.

Server ID, SID
   An identifier that can be used to designate one of the participating
   Servers. In the context of DHCP, the SID is the IP address or DNS
   name of the server.

Service Transaction, ST
   A set of client-server exchanges that lead to a server providing or
   denying some service to a client. Example: the DISCOVER/OFFER/
   REQUEST/ACK message exchange between a DHCP server and client is a
   service transaction.

Service Transaction ID, STID
   An attribute of the individual client requests used for =
load-balancing.






Gonczi, et. al.          Expires March 2001                  [Page 2]
=0C
Internet Draft           DHC Load Balancing Algorithm      September =
2000


3.  Background and External Requirements

Because DHCP clients use UDP broadcasts to contact DHCP servers, a
client DHCPDISCOVER message may be received by more than one server. =
All
servers receiving such a broadcast may respond to the client, letting
the client choose which server it will use.

When a BOOTP relay agent is used, it typically forwards or rebroadcasts
client broadcasts to all configured servers, so a similar inefficiency
is present.

The optimization described allows a server to be chosen for each such
transaction by performing a "serve" / "do not serve" computation. A
forwarding agent can perform the same computation to choose a =
forwarding
destination.

In either case, the choice of server can be computed, without the
participants having to negotiate who is to respond.

The approach is probabilistic in nature, because it is nearly =
impossible
to foresee which client will request service next.  For short periods =
of
time, the actual percentage of clients served by a given server will
likely deviate from the desired percentage.  As the number of requests
grows, the actual percentage of the load being handled by each server
will approximate the configured percentage.

4. Overview

DHCP servers MUST use the Client Identifier option as the STID if it is
present.  If no Client Identifier option is present, the hlen field of
the DHCP packet MUST be used as the length of the data to be hashed, =
and
the contents of the chaddr MUST be the data to be hashed. At most
the first sixteen bytes of the Client Identifier or chaddr are used.

The proposal maps the STID into a hash value using the function in
section 6. The resulting hash value can then be used to decide who
should respond to the request, or who the forwarding target should be.

The provided hash function generates hash values 0 to 255, and yields a
fairly even hash bucket distribution for random STID-s, and also for
STID sequences that have some pattern. Resource allocation is
accomplished by assigning a set of specific hash values to each
participating server.

A server will only service a request if the STID hash of the request
matches one of its assigned hash values.

Any hash buckets not assigned to servers will result in some client =
ST-s
being entirely ignored. (In some scenarios, this may be a desirable
outcome).  STID-s need not be unique, but should have sufficient =
variety
to distribute load to each server.



Gonczi, et. al.          Expires March 2001                 [Page 3]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000


HBA-s MAY be transmitted as messages, encapsulated in messages of some
other protocol, e.g.: e-mail, or DHCP Failover Protocol option.

DHCP server implementations may optionally be configurable to handle a
case where load balancing is being done but the server that is supposed
to respond is not available, or is out of suitable addresses.

DHCP server implementations that provide this capability SHOULD set the
DS (Delayed Service) configuration parameter to the number of seconds =
to
wait after the client's first request has been sent before responding =
to
a client, where the hash would not normally permit the client to be
served.

A DHCP server providing this capability SHOULD use the value in the =
secs
field of the client request if its value is not zero. Because some
clients may not correctly implement the secs field, a DHCP server MAY
keep track of the first instance of a client transaction to which it
would not normally respond. If the server receives a request from a
client that has the same transaction ID as a previously recorded
request, and if the secs field in the second packet is zero, the DHCP
server MAY use the elapsed time (seconds) between the first and =
subsequent
client request, instead of the secs field.


5. Operation

5.1 Configuration

The configuration step consists of assigning hash values to available
servers. This is accomplished by providing one or more Hash Bucket
Assignments (HBA-s). These may come from a configuration file, the
Windows NT registry, EEPROM, etc. Alternatively, the hash bucket
values could be assigned using some agreed upon algorithm.
E.g.:"Every odd value is serviced by server A and every even value
is serviced by serber B".


5.2 HBA Intended for a Server

When configuring one specific server, an HBA in the form of a simple =
bit
map of 32 octet values SHOULD be used.

The first octet in the HBA bitmap represents HBA values 0-7, the next
byte values 8-15, and so on, with the thirty-second octet representing
values 248-255. In each octet, the least significant bit in that octet
represents the smallest HBA value in that octet.

Each bit of the HBA is associated with one possible hash value. If a =
bit
is set in the map, it means the recipient server MUST service each
client request, where the STID yields the corresponding hash value.




Gonczi, et. al.          Expires March 2001                 [Page 4]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000


For example, if a server is configured with an HBA of the following 32
octets:

	FF FF FF FF FF FF 00 00 ( 0   - 63 )
	FF FF FF FF FF FF FF FF ( 64 - 127 )
	00 00 00 00 00 00 00 00 (128 - 191 )
	00 00 00 00 00 00 00 00 (192 - 255 )

then it MUST service any client requests where the STID hashes into the
bucket values of 0 through 47 and 64 through 127.

5.3 Delayed Service Parameter

The Delayed Service parameter is optional.

If the parameter is not configured, the HBA sets up a strict Serve/Do
not serve policy.

If the parameter is configured, the server that is not supposed to =
serve
a specific request (based on the HBA and the STID hash), is allowed to
respond, after S seconds have elapsed since the client first attempted
to get service. A server MAY use the secs field in the BOOTP header for
determining the time since the client has been trying to get service,
or it MAY track repeated requests some other way.

5.4 HBA Intended for a Forwarder

When configuring a forwarding agent, (e.g.: BOOTP relay) HBA-s
consisting of pairs of Server-ID / Hash Bucket values MAY be used.

Here, the Server ID (SID) designates the server responsible for the
specified Hash Bucket. The forwarding agent forwards each client
request, where the STID yields the specified hash value, to the server
designated by the SID.

The Server ID may be any unique server attribute, (E.g.: IP address, =
DNS
name, etc) that is meaningful in the context of the relay agent
operation.

A forwarder may be configured to forward a given packet to more than =
one
server. For example, a BOOTP relay could be set up to split the load
between 2 primary-backup server pairs, each pair running the DHCP
Failover Protocol [FAILOVR]. In this case, a packet that is intended
for a server pair Will have to be forwarded to both the primary, and =
the
secondary server of the pair.




Gonczi, et. al.          Expires March 2001                 [Page 5]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000


A possible configuration file for a forwarding agent (e.g.: BOOTP =
relay)
may look like this:

192.33.43.11 192.33.43.12: 0..24;
192.33.43.13:  25..55;
192.33.43.15:  56..128;
192.33.43.16: 129 130 131 200..202;

The above configuration consists of 4 HBA-s. The first HBA example
reads: "Any Client request, where the STID yields a hash value 0 to 24,
will be forwarded to both server 192.33.43.11 and 192.33.43.12".

The 4th HBA example states: "Any Client request, where the STID yields =
a
hash value 129,139,131,200,201 or 202, will be forwarded to server
192.33.43.16.

6.  Hash Function for Load Balancing

The following hash function is a C language implementation of the
algorithm known as "Pearson's hash".  The Pearson's hash algorithm was
originally published in [PEARSON].

The hash function is computationally inexpensive, requires an array
lookup and xor operation for each key byte. To make this proposal work,
all interoperable implementations MUST use this hash function, with the
set of mixing table values given below:



















Gonczi, et. al.          Expires March 2001                 [Page 6]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000

/* A "mixing table" of 256 distinct values, in pseudo-random order. */

unsigned char  loadb_mx_tbl[256] =3D{
251, 175, 119, 215, 81, 14, 79, 191, 103, 49, 181, 143, 186, 157,  0,
232, 31, 32, 55, 60, 152, 58, 17, 237, 174, 70, 160, 144, 220, 90, 57,
223, 59,  3, 18, 140, 111, 166, 203, 196, 134, 243, 124, 95, 222, 179,
197, 65, 180, 48, 36, 15, 107, 46, 233, 130, 165, 30, 123, 161, 209, =
23,
97, 16, 40, 91, 219, 61, 100, 10, 210, 109, 250, 127, 22, 138, 29, 108,
244, 67, 207,  9, 178, 204, 74, 98, 126, 249, 167, 116, 34, 77, 193,
200, 121,  5, 20, 113, 71, 35, 128, 13, 182, 94, 25, 226, 227, 199, 75,
27, 41, 245, 230, 224, 43, 225, 177, 26, 155, 150, 212, 142, 218, 115,
241, 73, 88, 105, 39, 114, 62, 255, 192, 201, 145, 214, 168, 158, 221,
148, 154, 122, 12, 84, 82, 163, 44, 139, 228, 236, 205, 242, 217, 11,
187, 146, 159, 64, 86, 239, 195, 42, 106, 198, 118, 112, 184, 172, 87,
2, 173, 117, 176, 229, 247, 253, 137, 185, 99, 164, 102, 147, 45, 66,
231, 52, 141, 211, 194, 206, 246, 238, 56, 110, 78, 248, 63, 240, 189,
93, 92, 51, 53, 183, 19, 171, 72, 50, 33, 104, 101, 69, 8, 252, 83, =
120,
76, 135, 85, 54, 202, 125, 188, 213, 96, 235, 136, 208, 162, 129, 190,
132, 156, 38, 47, 1, 7, 254, 24, 4, 216, 131, 89, 21, 28, 133, 37, 153,
149, 80, 170, 68, 6, 169, 234, 151
};

unsigned char  loadb_p_hash(unsigned char *key,/* The key to be hashed =
*/
                           int len)           /* Key length in bytes  =
*/
{
unsigned char hash  =3D len;
int i;

	for (i=3Dlen ; i > 0 ;  )
	    hash =3D loadb_mx_tbl  [ hash ^ key[ --i ] ];

        return( hash );
}



An example of how to check if a server should service a transaction:


int accept_service_request(
	const unsigned char HBA[32],	/* The hash bucket bitmap */
	const unsigned char key,    	/* The service transaction id */
	const int len  )		/* length of the above */ )
{
unsigned char hash =3D loadb_p_hash(key,len);
int index          =3D (hash >> 3) & 31;
int bitmask        =3D 1 << (hash & 7);

        /* return 1 if we should service this transaction */
        return((HBA[index] & bitmask) !=3D 0);
}




Gonczi, et. al.          Expires March 2001                 [Page 7]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000


7.  Security

This proposal in and by itself provides no security, nor does it impact
existing security. Servers using this algorithm are responsible for
ensuring that if the contents of the HBA are transmitted over the
network as part of the process of configuring any server, that message
be secured against tampering, since tampering with the HBA could result
in denial of service for some or all clients.

8.  References

  [FAILOVR]  Kinnear, K,, Droms, R., Rabil, G., Dooley, M., Kapur, A.,
             Gonczi, S., Volz, B., "DHCP Failover  Protocol", Work in
             Progress.

  [PEARSON]  The Communications of the ACM  Vol.33, No.  6 (June 1990),
             pp. 677-680.

  [RFC2131]  R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
             March 1997.

  [RFC2219]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," RFC-2219, March 1997.


9.  Acknowledgements

Special thanks to Peter K. Pearson, the author of Pearson's hash who =
has
kindly granted his permission to use his algorithm, free of any
encumbrances.

This proposal stems from the original idea of hashing MAC addresses to =
a
single bit by Ted Lemon, during a Failover Protocol discussion held at
CISCO Systems in February, 1999. Rob Stevens suggested the potential =
use
of this algorithm for purposes beyond those of the Failover Protocol.

Many thanks to Ralph Droms, Kim Kinnear, Mark Stapp, Glenn Waters, Greg
Rabil and Jack Wong for their comments during the ongoing discussions.












Gonczi, et. al.          Expires March 2001                 [Page 8]
=0C
Internet Draft           DHC Load Balancing Algorithm     September =
2000


10.  Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved. This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,

provided that the above copyright notice and this paragraph are =
included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright =
notice
or references to the Internet Society or other Internet organizations,
except as needed for the  purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

11.  Author's information

Bernie Volz
IPWorks, Inc.
959 Concord Street Framingham, MA 01701
Phone: (508)-879-4785
EMail: volz@ipworks.com

Steve Gonczi
Network Engines, Inc.
25 Dan Road Canton, MA 02021-2817
Phone: 781-332-1165
Email: steve.gonczi@networkengines.com

Ted Lemon
950 Charter Street
Redwood City, CA 94043
EMail: ted.lemon@nominum.com

Rob Stevens
Join Systems, Inc.
1032 Elwell Ct Ste 243 Palo Alto CA 94203
Phone: (650)-968-4470
EMail: robs@join.com






Gonczi, et. al.           Expires March 2001                 [Page 9]

------_=_NextPart_000_01C03DE4.6B1AB888--



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-v4@bucknell.edu  Wed Oct 25 15:52:49 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03045
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 25 Oct 2000 15:52:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9PJmHb11742;
	Wed, 25 Oct 2000 15:48:17 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e9PJm9b20200
	for <dhcp-v4@bucknell.edu>; Wed, 25 Oct 2000 15:48:09 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA23514;
	Wed, 25 Oct 2000 15:47:49 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA27216;
	Wed, 25 Oct 2000 15:47: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 PAA24046; Wed, 25 Oct 2000 15:48:01 -0400
Message-Id: <200010251948.PAA24046@rotala.raleigh.ibm.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>, docsis-macup@cablelabs.com
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12 
In-Reply-To: Message from "Michael W. Patrick" <mpatrick@dma.isg.mot.com> 
   of "Thu, 19 Oct 2000 19:07:03 EDT." <200010192307.TAA07347@noah.dma.isg.mot.com> 
Date: Wed, 25 Oct 2000 15:48:01 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie Volz <Volz@ipworks.com> writes:

> In RFC 2131, in section 4.1 it states:

>    DHCP clients and servers both construct DHCP messages by filling in
>    fields in the fixed format section of the message and appending
>    tagged data items in the variable length option area.  The options
>    area includes first a four-octet 'magic cookie' (which was described
>    in section 3), followed by the options.  The last option must always
>    be the 'end' option.

> And, in RFC 2132, section 3.2 defines the 'end' option:

> 3.2. End Option

>    The end option marks the end of valid information in the vendor
>    field.  Subsequent octets should be filled with pad options.

>    The code for the end option is 255, and its length is 1 octet.

Got it. What had confused me was the reference above to "in the vendor
field". RFC 2131 uses "options" and the "vendor field" terminology
dates back to bootp.

"Michael W. Patrick" <mpatrick@dma.isg.mot.com> writes:

> I checked the Auth draft, and it explicitly
> says to include all options in order EXCLUDING any relay
> agent options (type 82) that may be present.  So the
> auth draft doesn't care where the 82 option is (either
> before or after END).  The auth draft does, however, care
> very much whether the END option got stripped, because the END is
> included in the authentication.

reading the text in <draft-ietf-dhc-authentication-14.txt:

3. Interaction with Relay Agents

   Because a DHCP relay agent may alter the values of the 'giaddr' and
    'hops' fields in the DHCP message, the contents of those two fields
   MUST be set to zero for the computation of any hash function over the
   message header. Additionally, a relay agent may append the DHCP relay
   agent information option 82 [7] as the last option in a message to
   servers. If a server finds option 82 included in a received message,
   the server MUST compute any hash function as if the option were NOT
   included in the message without changing the order of options.


It seems like the above wording might benefit from some tweaking. It
isn't enough to just zero out the agent option fields. It needs to be
removed and the end option shifted to take its place (and the length
of the packet over which the computation is performed needs to be
adjusted). I.e., the authentication check will fail unless its run
over the exact packet that was sent before the relay agent options got
added (and now, its not just appended, but inserted before the end
option). Make sense?

Thomas	



From owner-dhcp-v4@bucknell.edu  Wed Oct 25 16:33:17 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07646
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 25 Oct 2000 16:33:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9PKSnb12851;
	Wed, 25 Oct 2000 16:28:49 -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 e9PKSgb05251
	for <dhcp-v4@bucknell.edu>; Wed, 25 Oct 2000 16:28:42 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VRHK00QK>; Wed, 25 Oct 2000 16:28:26 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE860360718D@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: "Michael W. Patrick": dhcp agent options draft 12
Date: Wed, 25 Oct 2000 16:28: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: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Thomas:

I think the present wording is OK as it doesn't say to zero those fields out
- it says to REMOVE the option as it if were not present (it DOES say to
zero the 'giaddr' and 'hops' fields since they were zero when the
authentication was calculated).

Certainly if YOU think the wording "if the option were NOT included" is
confusing and open to interpretation, then we could change it.

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Wednesday, October 25, 2000 3:48 PM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list; docsis-macup@cablelabs.com
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12


Bernie Volz <Volz@ipworks.com> writes:

> In RFC 2131, in section 4.1 it states:

>    DHCP clients and servers both construct DHCP messages by filling in
>    fields in the fixed format section of the message and appending
>    tagged data items in the variable length option area.  The options
>    area includes first a four-octet 'magic cookie' (which was described
>    in section 3), followed by the options.  The last option must always
>    be the 'end' option.

> And, in RFC 2132, section 3.2 defines the 'end' option:

> 3.2. End Option

>    The end option marks the end of valid information in the vendor
>    field.  Subsequent octets should be filled with pad options.

>    The code for the end option is 255, and its length is 1 octet.

Got it. What had confused me was the reference above to "in the vendor
field". RFC 2131 uses "options" and the "vendor field" terminology
dates back to bootp.

"Michael W. Patrick" <mpatrick@dma.isg.mot.com> writes:

> I checked the Auth draft, and it explicitly
> says to include all options in order EXCLUDING any relay
> agent options (type 82) that may be present.  So the
> auth draft doesn't care where the 82 option is (either
> before or after END).  The auth draft does, however, care
> very much whether the END option got stripped, because the END is
> included in the authentication.

reading the text in <draft-ietf-dhc-authentication-14.txt:

3. Interaction with Relay Agents

   Because a DHCP relay agent may alter the values of the 'giaddr' and
    'hops' fields in the DHCP message, the contents of those two fields
   MUST be set to zero for the computation of any hash function over the
   message header. Additionally, a relay agent may append the DHCP relay
   agent information option 82 [7] as the last option in a message to
   servers. If a server finds option 82 included in a received message,
   the server MUST compute any hash function as if the option were NOT
   included in the message without changing the order of options.


It seems like the above wording might benefit from some tweaking. It
isn't enough to just zero out the agent option fields. It needs to be
removed and the end option shifted to take its place (and the length
of the packet over which the computation is performed needs to be
adjusted). I.e., the authentication check will fail unless its run
over the exact packet that was sent before the relay agent options got
added (and now, its not just appended, but inserted before the end
option). Make sense?

Thomas	



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-v4@bucknell.edu  Thu Oct 26 06:22:11 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10873
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 26 Oct 2000 06:22:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9QAIUb21928;
	Thu, 26 Oct 2000 06:18:30 -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 e9QAINb31982
	for <dhcp-v4@bucknell.edu>; Thu, 26 Oct 2000 06:18:24 -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 GAA02741;
	Thu, 26 Oct 2000 06:18:18 -0400
Message-Id: <200010261018.GAA02741@hygro.adsl.duke.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 25 Oct 2000 16:28:26 EDT." <63D30D6E10CFD11190A90000F805FE860360718D@lespaul.process.com> 
Date: Thu, 26 Oct 2000 06:18:18 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie Volz <Volz@ipworks.com> writes:

> I think the present wording is OK as it doesn't say to zero those fields out
> - it says to REMOVE the option as it if were not present (it DOES say to
> zero the 'giaddr' and 'hops' fields since they were zero when the
> authentication was calculated).

I agree that the wording is technically correct.

> Certainly if YOU think the wording "if the option were NOT included" is
> confusing and open to interpretation, then we could change it.

My take is that an ounce of prevention is worth ...

There seems to be lots of experience that if there is any way for
someone to become confused about part of a spec, SOMEBODY inevitably
will... :-)

Thomas



From owner-dhcp-v4@bucknell.edu  Thu Oct 26 14:36:04 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04790
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 26 Oct 2000 14:36:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9QIULb19580;
	Thu, 26 Oct 2000 14:30:21 -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 e9QIUAb26625
	for <dhcp-v4@bucknell.edu>; Thu, 26 Oct 2000 14:30:11 -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 OAA19488; Thu, 26 Oct 2000 14:29:46 -0400 (EDT)
Message-Id: <4.2.0.58.20001026110436.01c52a50@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 26 Oct 2000 14:30:36 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: Failover Draft Conference Call, Friday Oct. 27
Cc: kkinnear@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: kkinnear@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

		
The first failover draft conference call will take place
tomorrow.  Friday October 27, 2000, at 12:00 EDT, and last for up
to 3 hours.  For most of you, that is tomorrow.

The people that have responded to me and can attend tomorrow's
call are:

	Bernie Volz	
	Steve Gonczi
	Ralph Droms
	Thomas Narten

I have sent them the call info just prior to this post.

Two other people responded with interest, but cannot attend the
Oct. 27 meeting:

	Greg Rabil
	Ted Lemon

My thinking is to schedule any followup call on November 7 or 8,
also at 12:00 EDT, in the hopes that we can have a broader set of
participants.

Topics for the Oct 27 meeting are (so far):

  a) Issues surrounding lease ownership and pool allocation
  for secondary servers.

  b) Handling of Dynamic bootp leases and "reservations.

  c) Massive resychronization required when bringing in 
  new secondary server.
	
If you want to attend the Friday Oct.  27 call and your name was
not on the list, please send me email (if I missed someone, I
apologize).

Cheers -- Kim

Kim Kinnear
Cisco Systems
(978) 244-8376






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



From owner-dhcp-v4@bucknell.edu  Fri Oct 27 16:51: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 QAA27674
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 27 Oct 2000 16:51:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9RKljb31074;
	Fri, 27 Oct 2000 16:47:45 -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 e9RKlgb07000
	for <dhcp-v4@bucknell.edu>; Fri, 27 Oct 2000 16:47:42 -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 QAA27881; Fri, 27 Oct 2000 16:47:25 -0400 (EDT)
Message-Id: <4.2.0.58.20001027144812.01c50f00@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 27 Oct 2000 16:48:15 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: minutes from failover draft conference call
Cc: kkinnear@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: kkinnear@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


We held a conference call today (Friday, October 27, 2000)
concerning the failover draft:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-07.txt

The following people attended (and a big thanks to all of them):

Ralph Droms       DHC WG chair        EDT   droms@bucknell.com
Steve Gonczi      Network Engines     EDT   Steve.Gonczi@networkengines.com
Richard Jones     Checkpoint Software PDT   richardj@sea.checkpoint.com
Kim Kinnear       Cisco Systems       EDT   kkinnear@cisco.com
Thomas Narten     IETF area dir       EDT   narten@raleigh.ibm.com
Mark Stapp        Cisco Systems       EDT   mjs@cisco.com

The following people wanted to attend, but this particular
date/time didn't work for them:

Bernie Volz       IPWorks             EDT   volz@ipworks.com
Greg Rabil        Lucent Technologies EDT   grabil@lucent.com
Ted Lemon         Nominum             EDT   mellon@nominum.org

The agenda was:

   a) Issues surrounding lease ownership and pool allocation for
   secondary servers.

   b) Handling of Dynamic bootp leases and "reservations.

   c) Massive resychronization required when bringing in new
   secondary server.

   d) What to do to move this draft towards last call?

   e) If and when should we do another failover conference call?


Here are the minutes (which I've written in third person for,
believe it or not, clarity):


----------------------------------------------------------
Issues surrounding lease ownership and pool allocation for
secondary servers.

We discussed the issues of lease ownership, loadbalancing, and
trying to balance the sizes of the pools of available leases on
the primary and secondary servers.

Steve Gonczi raised the issue that he felt that an IP address
should be owned by one server or another throughout its life
cycle, as opposed to the current model, where it is owned by one
server or another only when it is available.  He felt that this
would in general yield a more effective balance between the
available pools on the primary and secondary servers.

Kim Kinnear pointed out that in his view having IP addresses only
owned by one server or another when available wasn't the solution
to any problem with achieving a good balance between the failover
partner's available pool, since lease ownership wasn't really
that involved with the balancing issue.

Kim stated that, based on his thinking concerning Steve's issues,
that he felt that a more dynamic balancing approach should be
found that the current one, but that lease ownership didn't seem
like a solution (nor a problem).

After considerable discussion (approximately 45 minutes), we
discovered that we were imagining different models of use for the
protocol.  Steve was thinking of a 50/50 loadbalancing approach
with a 50/50 available IP address split -- and it seemed like
having the server's manage their "own" pool might cut the traffic
for having the primary pass addresses to the secondary.  Kim,
Mark Stapp, and Richard Jones all said that they were thinking
that people would sometimes use failover without loadbalancing at
all, and sometimes use loadbalancing very asymmetrically.  Kim
pointed out that he felt that a secondary server could not (in
general) wait for leases to expire as a way to replenish its pool
of available addresses, but that after using some addresses it
would have to have the main replenish its pool.

Steve pointed out that some of his concerns came from a real
failover implementation, but that it was operating in a testing
regime, where leases were very short and turned over a great
deal.  He generally agreed that the current approach to ownership
would work for him, since the environment in which it would be
used would probably need to have the secondary's available pool
replenished prior to any given lease expiring (that might be
owned by the secondary, and thus help to replenish the
secondary's pool of available addresses).

Kim said that he would work on a more dynamic balancing
mechanism, that was biased toward the primary making the
decisions -- to avoid having misconfigurations between the
partners turn into addresses flowing in a loop between them.
Richard said that he liked the idea of having the primary make
the IP address allocation decisions for the available leases for
the failover pair, since it yielded one place where the
parameters that would control this decision could be controlled.


---------------------------------------------------
Handling of Dynamic bootp leases and "reservations".

Steve brought up the need to tell the partner that a lease was
for a dynamic BOOTP client.  Kim mentioned that dynamic BOOTP was
in the draft, and that the problem wasn't with the information
that would flow about leases when the partners were
communicating.  He said that the problem was with the leases made
by one server when not communicating with the other server -- any
lease made from a pool which supports dynamic bootp will never
expire, and so the mclt has no meaning for any IP address in that
pool -- whether or not actually leased to a BOOTP device.  Thus,
any address pool which supports dynamic bootp will never be able
to be used by the partner, even in partner down.

We talked about reservations for a while.  Kim said that he
integrated the reservation work in the last round or two of the
draft, and Steve pointed out that it was not very well
integrated.  Kim said that he would take care of that.

Steve also said that, in his view, the reserved status of an IP
address was different from the state, and that having a state of
BACKUP-RESERVED was overloading the state in an unclean way.  Kim
responded that, as the reservation attribute was interesting only
when receiving the BNDUPD and only for available IP addresses
assigned to you, that this was not really a particularly
inelegant way to approach this problem (since both servers should
be configured to know that this IP address is reserved).  Richard
said that the BACKUP-RESERVED was a safety thing, to avoid a
problem with the servers were reconfigured at slightly different
times.  Steve was not entirely convinced, and still feels that
this approach is less clean than he would like, but agreed to
live with it., Kim said that, if another attribute appeared that
required transmission between failover partners, that he would
pull the BACKUP-RESERVED state and make it an attribute on the
BNDUPD along with the new bind update attribute.  At present
there are no other attributes that are not well transmitted in
the existing options and packet format.

There was general agreement that this was acceptable.


------------------------------------------------------
Massive resychronization required when bringing in new 
secondary server.

Kim pointed out that, when servers are being resychronized, where
the secondary server has not ever seen the primary but the
primary *has* seen a secondary, the secondary asked for the
primary to send it "everything".  The secondary knows in this
case that it has no information in its stable storage, so it
wouldn't technically have to get *everything*, but just the
"relevant" address information from the primary.  Kim proposed
adding a new message to get just the relevant (i.e., changed at
some point) information, to make this reintegration approach more
efficient than the one current in use.

Steve asked the excellent question about the value of sending any
lease state information in a BNDUPD that is not "relevant", i.e.,
what would be the value of sending information on a blank
database record (as he put it).

After some thought, the group realized that Steve was right, and
Kim agreed to recast the update request all to be only update
request all that is "relevant", i.e., what has changed since the
ground state of the server.

Steve asked if two failover servers could ever get out of sync,
and said that he felt that they couldn't.  Kim related a single
real situation where it appeared to happen due to a restoration
from a backup.  Steve said that given this, we needed some way to
trigger the failover pair to send all of the relevant stuff from
each to the other, and that if this were to be part of a user
capability, it could certainly be used to get two failover
partners back in sync.

Kim agreed to add this capability into the draft.


------------------------------------------------
What to do to move this draft towards last call?

Kim said that he had a new port number from Bernie, and that
other than the changes that he had from today, and from some
editorial comments he had received, he didn't know what else was
required.  Steve said that he'd send editorial comments, but the
group agreed that they didn't know of any other problems.  Kim
said he would propose that the draft go to last call after San
Diego IETF, and Ralph Droms said that he felt that was the best
way to approach this.  Ralph said that we should just put it to
last call let the process reveal any problems that people have
with the draft.


----------------------------------------------------------
If and when should we do another failover conference call?

We heard from Steve that Ted Lemon has implemented a considerable
portion of the recent failover drafts, and we decided to ensure
that the next (and probably the last this cycle) failover
conference call would be held at a date and time such that he
could attend, so that we could find out from him just what he's
learned when trying to implement the draft.  The tentative dates
are November 7 or November 8, 12-3 either day.  Kim said he'd
send out mail proposing this.

==========================================================

That's it for now.

Another *big* thanks to all who attended.

Cheers -- Kim



From owner-dhcp-v4@bucknell.edu  Fri Oct 27 17:00: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 RAA29544
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 27 Oct 2000 17:00:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9RKxMb25409;
	Fri, 27 Oct 2000 16:59:22 -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 e9RKx9b12567
	for <dhcp-v4@bucknell.edu>; Fri, 27 Oct 2000 16:59:09 -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 QAA29184; Fri, 27 Oct 2000 16:58:53 -0400 (EDT)
Message-Id: <4.2.0.58.20001027164902.01c8b5d0@funnel.cisco.com>
X-Sender: kkinnear@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 27 Oct 2000 16:59:42 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Kim Kinnear <kkinnear@cisco.com>
Subject: Failover draft conference call -- version 2
Cc: kkinnear@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: kkinnear@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

	
*****
** Conference Call Announcement to discuss the
** Failover draft -- you *must* reply to participate
** (unless you already did for today's call)
*****

We had a useful failover draft conference call today, and I sent
out minutes in a separate email.

During today's call, we decided to CANCEL the call that was
tentatively scheduled for Friday November 3, 2000.

We are currently looking at November 7 or 8 as possible dates for
the next (and hopefully last call).

If you have already replied to the previous email about today's
call, I will automatically inform you of the date, time, and
phone connection information for the next call (whether or not
you were able to attend today's call).

If you have not, please let me know the standard information:

    1.  Your name(s), affiliation, and TIME ZONE.

    2.  The topics in the current failover draft which you would
    like to discuss in a conference call.  Please order a list by
    priority.  Examples might be: conflict resolution,
    initialization between partner servers, etc.

    3.  Will either of the above dates work for you?  If not,
    please make some alternative proposals -- recognizing that
    time is short.

These will be toll free calls inside of the continental US. If
you are outside of the toll free area, and would need financial
assistance as a condition of participation in such a call, please
mention that and we'll see what we can work out.

Send your reply *only* to kkinnear@cisco.com (i.e., do *not*
reply to the whole dhcp-v4 list!).

Cheers -- Kim



From owner-dhcp-v4@bucknell.edu  Fri Oct 27 17:34:40 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 RAA07620
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 27 Oct 2000 17:34:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e9RLVab27206;
	Fri, 27 Oct 2000 17:31:36 -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 e9RLVQb31485
	for <dhcp-v4@bucknell.edu>; Fri, 27 Oct 2000 17:31:26 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <VRHLACY0>; Fri, 27 Oct 2000 17:31:10 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE86036071BC@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: minutes from failover draft conference call
Date: Fri, 27 Oct 2000 17:31:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Kim:

Excellent summary and thanks for getting it out so soon after the
discussion. Sorry I wasn't able to make the call.

Regarding the "Massive resychronization required when bringing in new
secondary server" issue, couldn't there be an assumption that when a
UPDREQALL was requested, that the requesting server assumes some initial
state for ALL addresses before making the request. Thus, only those
addresses that are in some way different from the initial state would
require a BNDUPD (I would assume the initial state is for all addresses to
be in FREE state with no client information). BTW: Is that assumption ever
explicitly stated? Is it needed? AND, isn't this actually a better way to go
if the servers have slightly different configurations (since in that case,
even if ALL was sent, all wouldn't really have been sent).

If that was done, what need is there for a new message? (And from the sounds
of it, that's what you might have concluded.)

You also indicate that there was a real life situation where a restored
backup of a server caused some interesting problems. I would guess that the
server was not asking for UPDREQALL but just UPDREQ? Or? Did the initial
state handling not detect this problem? Might we need some additional
protection during startup of the servers? Or, was the UPDREQALL not sending
'all'?

Regarding open issues, I think the security section still needed some work
(and that was on mine and Ted's plate at one point if I recall correctly).
Neither of us has done anything on it.

I would also like to get feedback from Ted and any operational experience he
might be able to relay.

- Bernie Volz
  IPWorks

-----Original Message-----
From: Kim Kinnear [mailto:kkinnear@cisco.com]
Sent: Friday, October 27, 2000 4:48 PM
To: DHCPv4 discussion list
Cc: kkinnear@cisco.com
Subject: minutes from failover draft conference call



We held a conference call today (Friday, October 27, 2000)
concerning the failover draft:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-07.txt

The following people attended (and a big thanks to all of them):

Ralph Droms       DHC WG chair        EDT   droms@bucknell.com
Steve Gonczi      Network Engines     EDT   Steve.Gonczi@networkengines.com
Richard Jones     Checkpoint Software PDT   richardj@sea.checkpoint.com
Kim Kinnear       Cisco Systems       EDT   kkinnear@cisco.com
Thomas Narten     IETF area dir       EDT   narten@raleigh.ibm.com
Mark Stapp        Cisco Systems       EDT   mjs@cisco.com

The following people wanted to attend, but this particular
date/time didn't work for them:

Bernie Volz       IPWorks             EDT   volz@ipworks.com
Greg Rabil        Lucent Technologies EDT   grabil@lucent.com
Ted Lemon         Nominum             EDT   mellon@nominum.org

The agenda was:

   a) Issues surrounding lease ownership and pool allocation for
   secondary servers.

   b) Handling of Dynamic bootp leases and "reservations.

   c) Massive resychronization required when bringing in new
   secondary server.

   d) What to do to move this draft towards last call?

   e) If and when should we do another failover conference call?


Here are the minutes (which I've written in third person for,
believe it or not, clarity):


----------------------------------------------------------
Issues surrounding lease ownership and pool allocation for
secondary servers.

We discussed the issues of lease ownership, loadbalancing, and
trying to balance the sizes of the pools of available leases on
the primary and secondary servers.

Steve Gonczi raised the issue that he felt that an IP address
should be owned by one server or another throughout its life
cycle, as opposed to the current model, where it is owned by one
server or another only when it is available.  He felt that this
would in general yield a more effective balance between the
available pools on the primary and secondary servers.

Kim Kinnear pointed out that in his view having IP addresses only
owned by one server or another when available wasn't the solution
to any problem with achieving a good balance between the failover
partner's available pool, since lease ownership wasn't really
that involved with the balancing issue.

Kim stated that, based on his thinking concerning Steve's issues,
that he felt that a more dynamic balancing approach should be
found that the current one, but that lease ownership didn't seem
like a solution (nor a problem).

After considerable discussion (approximately 45 minutes), we
discovered that we were imagining different models of use for the
protocol.  Steve was thinking of a 50/50 loadbalancing approach
with a 50/50 available IP address split -- and it seemed like
having the server's manage their "own" pool might cut the traffic
for having the primary pass addresses to the secondary.  Kim,
Mark Stapp, and Richard Jones all said that they were thinking
that people would sometimes use failover without loadbalancing at
all, and sometimes use loadbalancing very asymmetrically.  Kim
pointed out that he felt that a secondary server could not (in
general) wait for leases to expire as a way to replenish its pool
of available addresses, but that after using some addresses it
would have to have the main replenish its pool.

Steve pointed out that some of his concerns came from a real
failover implementation, but that it was operating in a testing
regime, where leases were very short and turned over a great
deal.  He generally agreed that the current approach to ownership
would work for him, since the environment in which it would be
used would probably need to have the secondary's available pool
replenished prior to any given lease expiring (that might be
owned by the secondary, and thus help to replenish the
secondary's pool of available addresses).

Kim said that he would work on a more dynamic balancing
mechanism, that was biased toward the primary making the
decisions -- to avoid having misconfigurations between the
partners turn into addresses flowing in a loop between them.
Richard said that he liked the idea of having the primary make
the IP address allocation decisions for the available leases for
the failover pair, since it yielded one place where the
parameters that would control this decision could be controlled.


---------------------------------------------------
Handling of Dynamic bootp leases and "reservations".

Steve brought up the need to tell the partner that a lease was
for a dynamic BOOTP client.  Kim mentioned that dynamic BOOTP was
in the draft, and that the problem wasn't with the information
that would flow about leases when the partners were
communicating.  He said that the problem was with the leases made
by one server when not communicating with the other server -- any
lease made from a pool which supports dynamic bootp will never
expire, and so the mclt has no meaning for any IP address in that
pool -- whether or not actually leased to a BOOTP device.  Thus,
any address pool which supports dynamic bootp will never be able
to be used by the partner, even in partner down.

We talked about reservations for a while.  Kim said that he
integrated the reservation work in the last round or two of the
draft, and Steve pointed out that it was not very well
integrated.  Kim said that he would take care of that.

Steve also said that, in his view, the reserved status of an IP
address was different from the state, and that having a state of
BACKUP-RESERVED was overloading the state in an unclean way.  Kim
responded that, as the reservation attribute was interesting only
when receiving the BNDUPD and only for available IP addresses
assigned to you, that this was not really a particularly
inelegant way to approach this problem (since both servers should
be configured to know that this IP address is reserved).  Richard
said that the BACKUP-RESERVED was a safety thing, to avoid a
problem with the servers were reconfigured at slightly different
times.  Steve was not entirely convinced, and still feels that
this approach is less clean than he would like, but agreed to
live with it., Kim said that, if another attribute appeared that
required transmission between failover partners, that he would
pull the BACKUP-RESERVED state and make it an attribute on the
BNDUPD along with the new bind update attribute.  At present
there are no other attributes that are not well transmitted in
the existing options and packet format.

There was general agreement that this was acceptable.


------------------------------------------------------
Massive resychronization required when bringing in new 
secondary server.

Kim pointed out that, when servers are being resychronized, where
the secondary server has not ever seen the primary but the
primary *has* seen a secondary, the secondary asked for the
primary to send it "everything".  The secondary knows in this
case that it has no information in its stable storage, so it
wouldn't technically have to get *everything*, but just the
"relevant" address information from the primary.  Kim proposed
adding a new message to get just the relevant (i.e., changed at
some point) information, to make this reintegration approach more
efficient than the one current in use.

Steve asked the excellent question about the value of sending any
lease state information in a BNDUPD that is not "relevant", i.e.,
what would be the value of sending information on a blank
database record (as he put it).

After some thought, the group realized that Steve was right, and
Kim agreed to recast the update request all to be only update
request all that is "relevant", i.e., what has changed since the
ground state of the server.

Steve asked if two failover servers could ever get out of sync,
and said that he felt that they couldn't.  Kim related a single
real situation where it appeared to happen due to a restoration
from a backup.  Steve said that given this, we needed some way to
trigger the failover pair to send all of the relevant stuff from
each to the other, and that if this were to be part of a user
capability, it could certainly be used to get two failover
partners back in sync.

Kim agreed to add this capability into the draft.


------------------------------------------------
What to do to move this draft towards last call?

Kim said that he had a new port number from Bernie, and that
other than the changes that he had from today, and from some
editorial comments he had received, he didn't know what else was
required.  Steve said that he'd send editorial comments, but the
group agreed that they didn't know of any other problems.  Kim
said he would propose that the draft go to last call after San
Diego IETF, and Ralph Droms said that he felt that was the best
way to approach this.  Ralph said that we should just put it to
last call let the process reveal any problems that people have
with the draft.


----------------------------------------------------------
If and when should we do another failover conference call?

We heard from Steve that Ted Lemon has implemented a considerable
portion of the recent failover drafts, and we decided to ensure
that the next (and probably the last this cycle) failover
conference call would be held at a date and time such that he
could attend, so that we could find out from him just what he's
learned when trying to implement the draft.  The tentative dates
are November 7 or November 8, 12-3 either day.  Kim said he'd
send out mail proposing this.

==========================================================

That's it for now.

Another *big* thanks to all who attended.

Cheers -- Kim