From owner-dhcp-v4@bucknell.edu Thu Mar 1 09:24:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04791 for ; Thu, 1 Mar 2001 09:24:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21EG1L18778; Thu, 1 Mar 2001 09:16:01 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f21EFrL10866 for ; Thu, 1 Mar 2001 09:15:54 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f21EDVM03955 for ; Thu, 1 Mar 2001 09:13:31 -0500 Message-Id: <200103011413.f21EDVM03955@hygro.adsl.duke.edu> To: DHCPv4 discussion list Subject: FWD: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS Date: Thu, 01 Mar 2001 09:13:31 -0500 From: Thomas Narten 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 Can anyone here comment on how to do this? (please cc original author and/or ipcdn list). Thomas ------- Forwarded Message From: "Pirozzi, Timothy (Max Power)" To: "'Kirk Friedman'" Cc: ipcdn@ietf.org Date: Thu, 1 Mar 2001 07:27:35 -0500 Subject: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS Hi Kirk, If I could obtain the IP and MAC from the DHCP server via SNMP then that would be great. But I haven't found any standard MIBs like that or any proprietary MIBs. I know for a fact that right now ISPs and the like are having to dump a file from their DHCP server with MAC and IP information and repopulate their NMS every morning with that information. If the information is not available via SNMP then it is not a practical solution. That's why I am trying to champion this request. Now maybe the solution is the DHCP server I'm not saying it isn't. But it seems some vendors are already implementing proprietary versions of such a trap. I think it would be better for this working group to define a standard trap or table of some sort for all to follow. Thanks Tim >-----Original Message----- >From: Kirk Friedman [mailto:kfriedman@correlant.com] >Sent: Wednesday, February 28, 2001 10:07 PM >To: 'Daniel Hegglin'; azlina@cisco.com; Pirozzi, Timothy (Max Power) >Cc: ipcdn@ietf.org >Subject: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS > > >Hi Dan, > > In answer to your comments below, yes a CMTS could use >the IP address >from registration. And if the IP address on the CM is changed >how would >that be evident to the CMTS w/out DHCP snooping? Also, as you >said, it is >not a required TLV. > > Again, traps can be lost between the CMTS and the NMS. >How would the >NMS know if a IP address to CM address association had been >lost if the >trap never arrived? If the CMTS keeps a trap table, then this >is also a >new requirement and you run into issues of how big the table might get >after a power outage at the CMTS or CM side with large numbers of >registrations, how often does the management system check the >table, what >to do about those traps that never made it (table continues to grow >because entries aren't deleted)? > > I still feel that the best solution is at the source that >is granting >the IP addresses, the DHCP server. It knows the CM mac >address, the CM IP >address, can distinguish between CM and CPE IP addresses and >knows that a >CM has actually done a REQUEST on the offered IP address. > >Kirk Friedman >Correlant Communications (formerly TurboNet Communications) >15110 Avenue Of Science >San Diego, CA., 92128-3405 >Ph: 858-451-1061 x105 >Fax: 858-451-1061 x1775 >kfriedman@correlant-comm.com > > >-----Original Message----- >From: Daniel Hegglin [SMTP:dhegglin@riverstonenet.com] >Sent: Wednesday, February 28, 2001 3:32 PM >To: Kirk Friedman; azlina@cisco.com; Pirozzi, Timothy (Max Power) >Cc: ipcdn@ietf.org >Subject: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS > >Hi, > >I might as well jump in here. I'm not advocating that the >CMTS should be >required to send traps on behalf of the CMs, but it would not be very >difficult to implement. > >> I don't agree that a CMTS should send these traps on behalf of a >> CM. This >> was discussed as a possibility in the DOCSIS Account >> Management/OSS meeting >> last year ( August 25 ) and rejected. The only way I am >aware of for a >> CMTS to really keep up with the CMs IP address is to keep track >> of the DHCP >> Acknowledgement from the DHCP server to the CM. The DHCP >> acknowledgments >> have to be used because there could be multiple DHCP servers >sending DHCP >> offers to a CM. A bridging CMTS is not directly involved >with layer 3 >> traffic and requiring it to snoop and keep track of this in >order to send >> traps to the CMTS was deemed too burdensome. > >A CMTS could use the IP address sent in the CM registration >message. This >is currently not a required field, but almost all modem >vendors send this >information upstream. > >> The second reason that you would not want the CMTS, or even the >> CM, to send >> the trap was because the trap could be lost. A discussion of >> using INFORM >> Trap type ( requires confirmation ) could eliminate the lost trap >> issue but >> that also lead to another discussion of what to do if the >INFORM is not >> acknowledged and it also requires the CMTS (or CM) to keep a >> state machine >> going for the INFORM until its acknowledged. > >Regular traps should be fine as long as the traps are logged in a trap >table. A management station can destroy the row after reading >the data so >the table doesn't get too big. > >dan > > >Daniel Hegglin >Riverstone Networks >5200 Great America Parkway >Santa Clara, CA 95054 >(408) 878-6526 - work >http://www.riverstonenet.com/ > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn ------- End of Forwarded Message From owner-dhcp-v6@bucknell.edu Thu Mar 1 09:48:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05665; Thu, 1 Mar 2001 09:48:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21EinL04527; Thu, 1 Mar 2001 09:44:49 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f21EigL18155 for ; Thu, 1 Mar 2001 09:44:42 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f21Eifi22277 for ; Thu, 1 Mar 2001 08:44:41 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f21EifU27753 for ; Thu, 1 Mar 2001 08:44:41 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 01 08:46:07 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 08:46:06 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69353DF2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A proposal for DHCPv6 reconfiguration Date: Thu, 1 Mar 2001 08:46:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A25E.576B9DF0" 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 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_001_01C0A25E.576B9DF0 Content-Type: text/plain; charset="iso-8859-1" Ralph: What are the requirements on the client as to how long it must retain the XID (and server address) for RECONFIGURE-INIT messages that it receives? Must it just keep one per server? Or? For how long must these be retained (5 minutes, until reboot)? I also agree with Erik that the delay parameter should be required, not optional. >As an aside, the behavior of a client that receives a >Reconfigure-init while expecting an Advertise or Reply >is not currently defined and is TBD. Regarding this issue, are you referring to whether the client sends a Reply to the Reconfigure-Init or whether the client does the reconfiguration? I do think it should send a Reply (that way, if the server is keeping track of the clients, it can know that this client responded). Whether the client does the reconfigure depends on whether it has already obtained any configuration information or not. If it is waiting for an Advertise (and has no configuration data), it should just continue. If waiting for a Reply, I would think it best to continue waiting for that Reply and reconfiguring afterwards? - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Tuesday, February 27, 2001 6:14 PM To: DHCPv6 discussion list Subject: A proposal for DHCPv6 reconfiguration Jim and I are finishing up the -17 rev of the DHCPv6 spec. I never saw any response to the following message. Unless I hear something different, this is what will go in the spec. - Ralph Assuming I got the list of multicast reconfigure issues from San Diego right, here is a list of goals for server-initiated configuration: * When the server has a complete list of the clients to be reconfigured, the server will know reliably that each client has either been reconfigured exactly once or has not responded to the server's reconfiguration request * When the server does not have a complete list of clients, the server will have some assurance that each client has received at least one Reconfigure-init message * Wherever possible, redundant or gratuitous reconfiguration of clients will be avoided (even though reconfiguring more than once should not affect correct client operation) * Clients and servers must be able to authenticate Reconfigure-init messages, to avoid denial-of-service attacks Here's my proposal for server-initiated configuration, intended to meet the listed goals (except for multicast authentication, which I don't have a solution for): Reliable unicast transmission can be managed through the use of the transaction-id. The server includes a unique transaction ID in each unicast Reconfigure-init message. The client responds to the first Reconfigure-init message it receives, copying the transaction ID into the Reply message the client sends to the server, and ignores all subsequent Reconfigure-init messages with the same transaction ID. This behavior causes the client to ignore duplicate copies of a single Reconfigure-init message. If the server does not receive a Reply to the Reconfigure-init with a matching transaction ID, the server can try again by transmitting a new Reconfigure-init with a new transaction ID. The new transaction ID will cause the client to start the reconfiguration process again, in case the client did not receive earlier Reconfigure-init messages or the server did not receive the client's Reply. The delay before a server retries with a new Reconfigure-init, the number of times the server should retry before giving up and the server's action when it can't reach a client are TBD. As an aside, the behavior of a client that receives a Reconfigure-init while expecting an Advertise or Reply is not currently defined and is TBD. For reconfiguration using multicast, the server multicasts an initial message Reconfigure-init several times with the same transaction ID. The number of retransmissions and the delay between retransmissions is TBD. The client behavior is the same as in the unicast Reocnfigure-inti message: each client in the multicast group to which the Reconfigure-init message was transmitted responds to first message it receives (not necessarily the first message transmitted by the server) and ignores all other Reconfigure-init messages with the same transaction ID. The server maintains a list of those clients that have responded to the multicast Reconfigure-init message. After the multicast Reconfigure-init messages have been transmitted, the server reverts to unicast with new transaction ID for clients that have not responded respond. To reduce the number of simultaneous Replies recieved by a server, the server can include a delay parameter in the Reconfigure-init message. Clients then choose random time between 0 and the delay parameter to respond with a Reply message. ------_=_NextPart_001_01C0A25E.576B9DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A proposal for DHCPv6 reconfiguration

Ralph:

What are the requirements on the client as to how = long it must retain the XID (and server address) for RECONFIGURE-INIT = messages that it receives? Must it just keep one per server? Or? For = how long must these be retained (5 minutes, until reboot)?

I also agree with Erik that the delay parameter = should be required, not optional.

>As an aside, the behavior of a client that = receives a
>Reconfigure-init while expecting an Advertise or = Reply
>is not currently defined and is TBD.

Regarding this issue, are you referring to whether = the client sends a Reply to the Reconfigure-Init or whether the client = does the reconfiguration? I do think it should send a Reply (that way, = if the server is keeping track of the clients, it can know that this = client responded). Whether the client does the reconfigure depends on = whether it has already obtained any configuration information or not. = If it is waiting for an Advertise (and has no configuration data), it = should just continue. If waiting for a Reply, I would think it best to = continue waiting for that Reply and reconfiguring = afterwards?

- Bernie Volz
  Ericsson



-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]=
Sent: Tuesday, February 27, 2001 6:14 PM
To: DHCPv6 discussion list
Subject: A proposal for DHCPv6 = reconfiguration


Jim and I are finishing up the -17 rev of the DHCPv6 = spec.  I never saw any
response to the following message.  Unless I = hear something different, this
is what will go in the spec.

- Ralph


Assuming I got the list of multicast reconfigure = issues from San Diego
right, here is a list of goals for server-initiated = configuration:

* When the server has a complete list of the clients = to be
   reconfigured, the server will know = reliably that each
   client has either been reconfigured = exactly once or has
   not responded to the server's = reconfiguration request
* When the server does not have a complete list of = clients,
   the server will have some assurance = that each client has
   received at least one Reconfigure-init = message
* Wherever possible, redundant or gratuitous = reconfiguration
   of clients will be avoided (even though = reconfiguring
   more than once should not affect = correct client operation)
* Clients and servers must be able to = authenticate
   Reconfigure-init messages, to avoid = denial-of-service
   attacks

Here's my proposal for server-initiated = configuration, intended
to meet the listed goals (except for multicast = authentication,
which I don't have a solution for):

Reliable unicast transmission can be managed through = the use of the
transaction-id.  The server includes a unique = transaction ID in each
unicast Reconfigure-init message.  The client = responds to the first
Reconfigure-init message it receives, copying the = transaction ID into
the Reply message the client sends to the server, = and ignores all
subsequent Reconfigure-init messages with the same = transaction ID.
This behavior causes the client to ignore duplicate = copies of a single
Reconfigure-init message.  If the server does = not receive a Reply to
the Reconfigure-init with a matching transaction ID, = the server can
try again by transmitting a new Reconfigure-init = with a new
transaction ID.  The new transaction ID will = cause the client to start
the reconfiguration process again, in case the = client did not receive
earlier Reconfigure-init messages or the server did = not receive the
client's Reply.  The delay before a server = retries with a new
Reconfigure-init, the number of times the server = should retry before
giving up and the server's action when it can't = reach a client are
TBD.

As an aside, the behavior of a client that receives = a
Reconfigure-init while expecting an Advertise or = Reply
is not currently defined and is TBD.

For reconfiguration using multicast, the server = multicasts an initial
message Reconfigure-init several times with the same = transaction ID.
The number of retransmissions and the delay between = retransmissions is
TBD.  The client behavior is the same as in the = unicast
Reocnfigure-inti message: each client in the = multicast group to which
the Reconfigure-init message was transmitted = responds to first message
it receives (not necessarily the first message = transmitted by the
server) and ignores all other Reconfigure-init = messages with the same
transaction ID.  The server maintains a list of = those clients that
have responded to the multicast Reconfigure-init = message.  After the
multicast Reconfigure-init messages have been = transmitted, the server
reverts to unicast with new transaction ID for = clients that have not
responded respond.

To reduce the number of simultaneous Replies recieved = by a server,
the server can include a delay parameter in the = Reconfigure-init
message.  Clients then choose random time = between 0 and the
delay parameter to respond with a Reply = message.

------_=_NextPart_001_01C0A25E.576B9DF0-- From owner-dhcp-v6@bucknell.edu Thu Mar 1 10:24:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07063; Thu, 1 Mar 2001 10:24:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21FLYL32492; Thu, 1 Mar 2001 10:21:35 -0500 (EST) 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 f21FL7L22850 for ; Thu, 1 Mar 2001 10:21:08 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-156.cisco.com [161.44.133.156]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14507 for ; Thu, 1 Mar 2001 10:20:51 -0500 (EST) Message-Id: <4.3.2.7.2.20010301100405.00b8f8c0@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 10:20:45 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: A proposal for DHCPv6 reconfiguration In-Reply-To: <66F66129A77AD411B76200508B65AC69353DF2@eambunt705.ena-east .ericsson.se> 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 08:46 AM 3/1/2001 -0600, you wrote: >What are the requirements on the client as to how long it must retain the >XID (and server address) for RECONFIGURE-INIT messages that it receives? >Must it just keep one per server? Or? For how long must these be retained >(5 minutes, until reboot)? I don't know - TBD. Off the top of my head, I'd say keep info on all messages for twice the maximum retransmission duration (i.e., time over which a server will retransmit) for a multicast message. I compute the total server retransmission time to be 2047 seconds (about 35 minutes) using the numbers in the current draft, so I would suggest we have the client hold on to the Reconfigure-init message information for an hour. >I also agree with Erik that the delay parameter should be required, not >optional. Suppose we define a mandatory default that can be optionally modified? > >As an aside, the behavior of a client that receives a > >Reconfigure-init while expecting an Advertise or Reply > >is not currently defined and is TBD. > >Regarding this issue, are you referring to whether the client sends a >Reply to the Reconfigure-Init or whether the client does the >reconfiguration? I do think it should send a Reply (that way, if the >server is keeping track of the clients, it can know that this client >responded). Whether the client does the reconfigure depends on whether it >has already obtained any configuration information or not. If it is >waiting for an Advertise (and has no configuration data), it should just >continue. If waiting for a Reply, I would think it best to continue >waiting for that Reply and reconfiguring afterwards? In the current spec, clients respond to a Reconfigure-init with a Request message (this is the "reconfigure as trigger" model). Only servers send Reply messages in the current spec. We could specify that the client always initiates a Request-Reply transaction when it receives a Reconfigure-init, regardless of the client's current state. Here are the two cases: * Sent Solicit, waiting for Advertise - client is looking for a server. It can use the server in the Reconfigure-init and send a Request to that server * Sent Request/Renew/Rebind, waiting for Reply - info in Reply after Reconfigure-init is likely to be more current than in Reply to previous message, so send new Request and ignore Reply to earlier message - Ralph From owner-dhcp-v6@bucknell.edu Thu Mar 1 10:44:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07689; Thu, 1 Mar 2001 10:44:37 -0500 (EST) Received: from localhost (LOCALHOST [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21FgQL09974; Thu, 1 Mar 2001 10:42:26 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f21Fg8L26701 for ; Thu, 1 Mar 2001 10:42:08 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f21Fg4i14224 for ; Thu, 1 Mar 2001 09:42:04 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f21Fg4U24050 for ; Thu, 1 Mar 2001 09:42:04 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 01 09:43:15 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 09:43:15 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F64F7@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A proposal for DHCPv6 reconfiguration Date: Thu, 1 Mar 2001 09:43:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A266.51DDD3F0" 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 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_001_01C0A266.51DDD3F0 Content-Type: text/plain; charset="iso-8859-1" See below (prefixed by BV>). -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, March 01, 2001 10:21 AM To: DHCPv6 discussion list Subject: RE: A proposal for DHCPv6 reconfiguration At 08:46 AM 3/1/2001 -0600, you wrote: >What are the requirements on the client as to how long it must retain the >XID (and server address) for RECONFIGURE-INIT messages that it receives? >Must it just keep one per server? Or? For how long must these be retained >(5 minutes, until reboot)? I don't know - TBD. Off the top of my head, I'd say keep info on all messages for twice the maximum retransmission duration (i.e., time over which a server will retransmit) for a multicast message. I compute the total server retransmission time to be 2047 seconds (about 35 minutes) using the numbers in the current draft, so I would suggest we have the client hold on to the Reconfigure-init message information for an hour. >I also agree with Erik that the delay parameter should be required, not >optional. Suppose we define a mandatory default that can be optionally modified? BV> That would also work. But, it means another client side configuration parameter BV> and specifying a default value. I'd prefer to have to set it in ONE place BV> and so I'd prefer to make it mandatory on the server. Of course, it would be BV> sent as an option, so the question is what is a client to do if there is no BV> option - I'd say IGNORE the Reconfigure-Init as it is a bogus request. > >As an aside, the behavior of a client that receives a > >Reconfigure-init while expecting an Advertise or Reply > >is not currently defined and is TBD. > >Regarding this issue, are you referring to whether the client sends a >Reply to the Reconfigure-Init or whether the client does the >reconfiguration? I do think it should send a Reply (that way, if the >server is keeping track of the clients, it can know that this client >responded). Whether the client does the reconfigure depends on whether it >has already obtained any configuration information or not. If it is >waiting for an Advertise (and has no configuration data), it should just >continue. If waiting for a Reply, I would think it best to continue >waiting for that Reply and reconfiguring afterwards? In the current spec, clients respond to a Reconfigure-init with a Request message (this is the "reconfigure as trigger" model). Only servers send Reply messages in the current spec. BV> I was using terminology from your original message. Such as: BV> "If the server does not receive a Reply to the Reconfigure-init BV> with a matching transaction ID ...". So, hopefully that text did not BV> come from the draft. We could specify that the client always initiates a Request-Reply transaction when it receives a Reconfigure-init, regardless of the client's current state. Here are the two cases: * Sent Solicit, waiting for Advertise - client is looking for a server. It can use the server in the Reconfigure-init and send a Request to that server BV> In this case, it seems better to ignore the Reconfigure-Init unless the BV> client already has addresses and then it should do the Request to the BV> server. * Sent Request/Renew/Rebind, waiting for Reply - info in Reply after Reconfigure-init is likely to be more current than in Reply to previous message, so send new Request and ignore Reply to earlier message BV> That sounds OK. - Ralph BV> Another issue, if the Reconfigure-Init causes a Request, the Transaction-ID BV> for the Request can't really be copied from the Reconfigure-Init as that BV> would mix two transaction-Id number spaces (one from the client and one from BV> the server). Did we solve this by having a "Reconfigure-XID" option that is BV> used by the client to specify that the Request is in response to a BV> Reconfigure-Init with the transaction ID in the message? Or am I confused. ------_=_NextPart_001_01C0A266.51DDD3F0 Content-Type: text/html; charset="iso-8859-1" RE: A proposal for DHCPv6 reconfiguration

See below (prefixed by BV>).

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, March 01, 2001 10:21 AM
To: DHCPv6 discussion list
Subject: RE: A proposal for DHCPv6 reconfiguration


At 08:46 AM 3/1/2001 -0600, you wrote:
>What are the requirements on the client as to how long it must retain the
>XID (and server address) for RECONFIGURE-INIT messages that it receives?
>Must it just keep one per server? Or? For how long must these be retained
>(5 minutes, until reboot)?

I don't know - TBD.  Off the top of my head, I'd say keep info on all
messages for twice the maximum retransmission duration (i.e., time over
which a server will retransmit) for a multicast message.  I compute the
total server retransmission time to be 2047 seconds (about 35 minutes)
using the numbers in the current draft, so I would suggest we have the
client hold on to the Reconfigure-init message information for an hour.

>I also agree with Erik that the delay parameter should be required, not
>optional.

Suppose we define a mandatory default that can be optionally modified?

BV> That would also work. But, it means another client side configuration parameter
BV> and specifying a default value. I'd prefer to have to set it in ONE place
BV> and so I'd prefer to make it mandatory on the server. Of course, it would be
BV> sent as an option, so the question is what is a client to do if there is no
BV> option - I'd say IGNORE the Reconfigure-Init as it is a bogus request.

> >As an aside, the behavior of a client that receives a
> >Reconfigure-init while expecting an Advertise or Reply
> >is not currently defined and is TBD.
>
>Regarding this issue, are you referring to whether the client sends a
>Reply to the Reconfigure-Init or whether the client does the
>reconfiguration? I do think it should send a Reply (that way, if the
>server is keeping track of the clients, it can know that this client
>responded). Whether the client does the reconfigure depends on whether it
>has already obtained any configuration information or not. If it is
>waiting for an Advertise (and has no configuration data), it should just
>continue. If waiting for a Reply, I would think it best to continue
>waiting for that Reply and reconfiguring afterwards?

In the current spec, clients respond to a Reconfigure-init with a Request
message (this is the "reconfigure as trigger" model). Only servers send
Reply messages in the current spec.

BV> I was using terminology from your original message. Such as:
BV> "If the server does not receive a Reply to the Reconfigure-init
BV> with a matching transaction ID ...". So, hopefully that text did not
BV> come from the draft.

We could specify that the client always initiates a Request-Reply
transaction when it receives a Reconfigure-init, regardless of the client's
current state.  Here are the two cases:

* Sent Solicit, waiting for Advertise - client is
   looking for a server.  It can use the server in
   the Reconfigure-init and send a Request to that
   server
BV> In this case, it seems better to ignore the Reconfigure-Init unless the
BV> client already has addresses and then it should do the Request to the
BV> server.

* Sent Request/Renew/Rebind, waiting for Reply - info
   in Reply after Reconfigure-init is likely to be more
   current than in Reply to previous message, so send
   new Request and ignore Reply to earlier message
BV> That sounds OK.

- Ralph

BV> Another issue, if the Reconfigure-Init causes a Request, the Transaction-ID
BV> for the Request can't really be copied from the Reconfigure-Init as that
BV> would mix two transaction-Id number spaces (one from the client and one from
BV> the server). Did we solve this by having a "Reconfigure-XID" option that is
BV> used by the client to specify that the Request is in response to a
BV> Reconfigure-Init with the transaction ID in the message? Or am I confused.

------_=_NextPart_001_01C0A266.51DDD3F0-- From owner-dhcp-v6@bucknell.edu Thu Mar 1 10:46:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07746; Thu, 1 Mar 2001 10:46:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21FiVL13134; Thu, 1 Mar 2001 10:44:31 -0500 (EST) 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 f21FiKL21690 for ; Thu, 1 Mar 2001 10:44:20 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-156.cisco.com [161.44.133.156]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17439 for ; Thu, 1 Mar 2001 10:44:04 -0500 (EST) Message-Id: <4.3.2.7.2.20010301091831.00bb6de0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 10:43:45 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHCPv6 spec, rev -17 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 will submit the -17 rev of the DHCPv6 spec draft this morning. If you want a preview, I'll put up a copy at www.dhcp.org until the draft gets through the IETF publication process. More details on agenda for 3/14 teleconference and WG meeting in Minneapolis will follow in another message. Here's a summary of the major new work in the -17 rev (see Appendix C in the draft for more details): * New messages for confirming addresses and extending the lease on an IA Four new messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP Decline, have been added and are described in section 13. Client behavior - when and how to send these new messages - and server behavior - how to respond to each - has been defined. The message type codes for these messages have been added to section 7.3. * New messages formats Section 9 has been restructured to include only one copy of the DHCP message header, because now all the messages have the same header format. Descriptions of the use of header fields in the Confirm, Renew, Rebind and Decline messages have been added to 9. * Clarified relay forwarding of messages Added text to sections on relay behavior to clarify encapsulation and decapsulation of client messages in Relay-forward and Relay-reply messages. * Addresses and options in Solicit, Advertise messages Modified section 12.4.2 so that servers include addresses to be assigned and other options in Advertise messages. Also added text to disallow option values (except as noted in option defs) in Solicit messages. * Specification of transaction ID in Solicit message Add text (which was missing) to specify the insertion of a transaction ID in Solicit messages. * Relay agent messages The formats of relay agent messages are now described in a separate section, 10. * Relay agent behavior The behavior of relay agents for all client and server messages is now described in a single section, 15. * Transmission of all client messages through relays All client messages are now multicast to the All Agents multicast address and forwarded by relays as appropriate. * Reconfigure-init messages Client behavior in response to a Reconfigure-init messages has been extended to accommodate receipt of multiple copies of a Reconfigure-init message due to duplicate messages or retransmission. Server use of multicast Reconfigure-init has been specified. Hints about use of multicast and unicast for reliable reconfiguration have been added to server implementor's hints. * Ordering of sections Several sections have been re-ordered for clarity. * DSTM option The DSTM option has been added (section 16.9). Here's what we *didn't* do, yet: * Authentication - we ran out of time (may get in a -18 rev before tomorrow's deadline) * Multicast authentication - no solution available yet * Anonymous addresses - waiting for requirements doc * Unique IDs for IAs (avoid indexing by prefix as well as DUID) - waiting for description of DUID selection mechanism * Additional options, data type descriptions in base spec, relay agent options - ran out of time (thanks for the input, Bernie - we'll get to it ASAP) * Delete operational parameters option (option to override defaults for client timeout, retransmission attempts, etc.) - no WG feedback on whether the option is a bug or a feature From owner-dhcp-v6@bucknell.edu Thu Mar 1 12:00:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10711; Thu, 1 Mar 2001 12:00:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21GvDL03318; Thu, 1 Mar 2001 11:57:13 -0500 (EST) 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 f21Gv5L18094 for ; Thu, 1 Mar 2001 11:57:05 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27707 for ; Thu, 1 Mar 2001 08:56:59 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA15286 for ; Thu, 1 Mar 2001 17:56:56 +0100 (MET) Date: Thu, 1 Mar 2001 17:55:51 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: A proposal for DHCPv6 reconfiguration To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <4.3.2.7.2.20010228123553.00b52a98@mail.bucknell.edu> Message-ID: 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 > How does the client differentiate between an intentional retransmission and > a duplicated Reconfigure-init? The client should remain silent when it > receives a duplicated Reconfigure-init. Exactly the same way TCP does. By NOT differentiating. Duplication by the network is rare so this doesn't normally cause a problem for TCP, except lowered performance for the TCP connection due to more ACKs being sent. But in any case, the proposed design looks reasonable now that I understand it a bit more. Erik From owner-dhcp-v4@bucknell.edu Thu Mar 1 12:01:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10767 for ; Thu, 1 Mar 2001 12:00:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21GrkL30791; Thu, 1 Mar 2001 11:53:46 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f21GreL25665 for ; Thu, 1 Mar 2001 11:53:40 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Thu, 1 Mar 2001 11:49:31 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 11:49:34 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E806F2AE9C@zwdld001.ca.nortel.com> From: "Biswaroop Mukherjee" To: DHCPv4 discussion list Cc: "Bill Gage" Subject: Re: why authenticate with DHCP? Date: Thu, 1 Mar 2001 11:49:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A26F.92D33A40" X-Orig: Reply-To: biswaroo@nortelnetworks.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_001_01C0A26F.92D33A40 Content-Type: text/plain; charset="iso-8859-1" > Please find my comments embedded below. > > On Wed, 28 Feb 2001, Bernard Aboba wrote: > > - >Are you assuming that all link layers will interface to AAA? > - > - Actually, network access does not interface to AAA directly. NASes > - act as gateways. So I don't think that this is a AAA question, it's > - a network access question. AAA can be made to work, regardless of > - the layer at which access control is enforced. > > 1. There is nothing to disagree above. An interface to AAA can be created > at several layers. But we believe that there may be factors that may argue > for providing an AAA interface at the DHCP level. Initial access and > configuration in commercial service provider networks has always involved > interfacing to the local AAA NAS. For instance the dial in user would send > his login information to the AAA NAS through PPP. PPP here was not just > used as a link layer(LCP), but also as an initial access configuration > protocol(NCP) for higher layers. If DHCP is to be used as an alternative, > (I will argue later that there is motivation for this too), we need to > address the issue of _interfacing_ to AAA. > > - > - >is it necessarily the right place to do it for all networks? > - > - I guess the answer to that depends on the ability to make a case > - for new MAC layers. I gather that 3G has investigated use of PPP > - or IEEE 802 framing, and concluded that this would not work. Can > - you share some of the reasoning behind that? > - > - I would note that in general, there seems to be a trend towards > - decreased MAC layer diversity. Just as we are moving to an IP > - Everywhere world, there is now movement towards Ethernet > - everywhere. So just as IP will displace IPX, AppleTalk, > - NetBEUI and SNA, so too will Ethernet displace Token Ring, ATM, > - FDDI, ARCnet and SONET. > > 2. I would not presume to know about Ethernet being as pervasive as IP. > But I see your point that Token Ring, ATM, FDDI, ARCnet etc. are seen less > commonly. But I do see a proliferation of different physical media and > associated protocols (e.g., fiber and a whole bunch of wireless > protocols). Because the link layer is closer to the physical media as > opposed to the network layer and deals with things like framing, I > would not discount the possibility that non-Ethernet like protocols will > be used for these new physical layers and thus gain popularity. In fact > the advocates of UTRAN will tell you that there is indeed an enormous > market that is expected to use their networks and thus their > link layer protocols. > > - > - That doesn't mean that creating a new MAC is unjustified; it just > - means that it's bucking a trend and needs to be thought through > - carefully. > - > - Will someone at the BURP BOF be taking about 3G MAC layers? > - > - >What about non-802.11 networks? > - > - I think there is some confusion about where authentication > - occurs in 802.11 and other IEEE 802 technologies. > - > - IEEE 802.1X authentication occurs above the 802.1 MAC layer, which > - means that it can be used by any IEEE 802 technology, including > - Ethernet (802.3), Token Ring (802.5), FDDI (ANSI), WLAN (802.11), > - PAN (802.16), etc. > - > - In IEEE 802.11b, authentication occurs below the 802.1 MAC layer. > - That is, WEP v1.0 packets are not visible to a conventional > - sniffer operating in promiscuous mode, although special 802.11 > - sniffers can get at it. > - > - This wasn't a smart thing to do because it requires changes to > - NIC and Access Point firmware in order to fix security bugs or > - add a new authentication method. The current intention is to > - move the authentication function above the MAC layer in WEP v2.0. > - > - > What about 3G networks? > - > - I'm not familiar enough with the 3G physical and data link proposals > - to give an opinion. But if 3G can honor the IEEE 802 hard and soft > - invariants, then it is a candidate for use of the IEEE 802.1 MAC, > - regardless of what the PHY is. > - > - Hard invariants: Nonduplication, Sequential delivery > - Soft invariants: Low delay, high bandwidth, low error rate > - > - Note that 802.11 honors these invariants even though it operates > - over the airwaves. The low error rate soft invariant (and sequential > - delivery) is honored via ARQ, and could conceivably be honored by > - other methods as well (e.g. FEC). > - > - The "low delay" invariant is relative; I've seen 802.11 installations > with > - delay of > 200 ms that still function. "High bandwidth" was said to > apply > - to the initial 802.11 implementations running at 1-2 Mbps, and I've seen > - applications using WAN mini-port drivers (e.g. latest Metricom cards) > run > - fine at 128 Kbps speeds. So "high bandwidth" is somewhat relative too. > - > - >Why not provide means of doing this at a higher layer, for instance > DHCP? > - > - I think that the architecture issues (layer 3/4 vs. layer 2) should be > kept > - separate from the implementation issues (DHCP vs. alternative > protocols). > - > - We might decide that layer 3 or layer 4 authentication makes sense in > some > - cases, but that wouldn't necessarily imply DHCP as a solution. I'm not > fond > - of using authenticated DHCP for access control because it wasn't > - developed to handle that scenario. After all, since a host can always > - choose a static address, authenticated DHCP by itself can't function as > - an access control mechanism. You need another mechanism, such as layer 3 > - filtering, in addition. See comments below relating to state > requirements. > > 3. I agree, DHCP was not meant for access control. I don't even know how > one could do the same. What I see it being useful for is as an initial > access > and configuration protocol for several types of access networks, > including the non-Ethernet ones. > > My point: > In some of the emerging access networks both 802.11 and PPP may > not be suitable points for authentication and interface to AAA, NOT > access control. DHCP with means for interfacing to AAA presents itself as > an alternative for the function of initial access and configuration of the > stack, thanks to its low administrative costs and the fact that it is to > a large extent agnostic to the lower layers. > > - > - Since George has expressed frustration that I always seem to be > answering > - questions with more questions, I thought I'd keep up the tradition ;) > - > - Here are the questions that you'd need to answer in order to justify > - doing authentication at layer 3 or above: > - > - 1. Is there a compelling reason to invent a new MAC layer rather than > just > - reusing PPP and IEEE 802? > > Addressed above in 2. > > - > - 2. Are we providing port access control, machine access control or user > - access control? Note that this is a separate issue from whether the > - identity claimed is that of a machine, user or group. > - > - Port access control requires the least state, since the maximum state > - required is in proportion to the number of ports on the NAS. > - > - Machine access control requires state for the maximum number of machines > - that can be connected to a NAS. If the NAS supports LAN technologies, > then > - the number of machines can be considerably larger than the number of > - ports. For example, if we need to authentication every node on a LAN > - at layer 3, we could end up with thousands of nodes in the filter table; > - this could impact throughput and increase cost. > - > - The state requirements for user access control are even larger -- you > could > - have multiple users per machine. > - > - Since state implies more hardware and higher cost as well as speed > - penalties, low cost/high speed devices have tended to support only > - port-based access control, which is the model implicitly assumed in > - PPP and 802.1X. > > As pointed above in 3, I do not see access control as a function of DHCP. > > - > - 3. If authentication is done at layer 3, how do we deal with > multi-protocol > - support? I am not thinking of AppleTalk, IPX, etc. so much as both IPv4 > and > - IPv6. Do we have an authentication per protocol, or can one > authentication > - be > - done that applies to all protocols? If authentication is done at layer > 4, > - do we authenticate all applications? If so, how would this differ from > - an application layer authentication framework such as SASL? > > I am advocating authentication for initial access and configuration via > DHCP. Application (service) level authentication is beyond the scope of an > initial access and configuration protocol as is access control. As far as > the question about IPv4/v6 support goes, the initial > configuration protocol (like DHCPv4/v6) that is responsible for getting > the v4/v6 stacks up and running can interface to AAA. > > Cheers, > -- Roop > ________________________________________ > > > > > ------_=_NextPart_001_01C0A26F.92D33A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: why authenticate with DHCP?

Please find my comments embedded = below.

On Wed, 28 Feb 2001, Bernard Aboba = wrote:

- >Are you assuming that all link = layers will interface to AAA?
-
- Actually, network access does not = interface to AAA directly. NASes
- act as gateways. So I don't think = that this is a AAA question, it's
- a network access question. AAA can = be made to work, regardless of
- the layer at which access control = is enforced.

1. There is nothing to disagree above. = An interface to AAA can be created
at several layers. But we believe = that there may be factors that may argue
for providing an AAA interface at the = DHCP level. Initial access and
configuration in commercial service = provider networks has always involved
interfacing to the local AAA NAS. For = instance the dial in user would send
his login information to the AAA NAS = through PPP. PPP here was not just
used as a link layer(LCP), but also = as an initial access configuration
protocol(NCP) for higher layers. If = DHCP is to be used as an alternative,
(I will argue later that there is = motivation for this too), we need to
address the issue of _interfacing_ to = AAA.

-
- >is it necessarily the right = place to do it for all networks?
-
- I guess the answer to that depends = on the ability to make a case
- for new MAC layers. I gather that = 3G has investigated use of PPP
- or IEEE 802 framing, and concluded = that this would not work. Can
- you share some of the reasoning = behind that?
-
- I would note that in general, there = seems to be a trend towards
- decreased MAC layer diversity. Just = as we are moving to an IP
- Everywhere world, there is now = movement towards Ethernet
- everywhere. So just as IP will = displace IPX, AppleTalk,
- NetBEUI and SNA, so too will = Ethernet displace Token Ring, ATM,
- FDDI, ARCnet and SONET.

2. I would not presume to know about = Ethernet being as pervasive as IP.
But I see your point that Token Ring, = ATM, FDDI, ARCnet etc. are seen less
commonly. But I do see a = proliferation of different physical media and
associated protocols (e.g., fiber and = a whole bunch of wireless
protocols). Because the link layer is = closer to the physical media as
opposed to the network layer and = deals with things like framing, I
would not discount the possibility = that non-Ethernet like protocols will
be used for these new physical layers = and thus gain popularity. In fact
the advocates of UTRAN will tell you = that there is indeed an enormous
market that is expected to use their = networks and thus their
link layer protocols.

-
- That doesn't mean that creating a = new MAC is unjustified; it just
- means that it's bucking a trend and = needs to be thought through
- carefully.
-
- Will someone at the BURP BOF be = taking about 3G MAC layers?
-
- >What about non-802.11 = networks?
-
- I think there is some confusion = about where authentication
- occurs in 802.11 and other IEEE 802 = technologies.
-
- IEEE 802.1X authentication occurs = above the 802.1 MAC layer, which
- means that it can be used by any = IEEE 802 technology, including
- Ethernet (802.3), Token Ring = (802.5), FDDI (ANSI), WLAN (802.11),
- PAN (802.16), etc.
-
- In IEEE 802.11b, authentication = occurs below the 802.1 MAC layer.
- That is, WEP v1.0 packets are not = visible to a conventional
- sniffer operating in promiscuous = mode, although special 802.11
- sniffers can get at it.
-
- This wasn't a smart thing to do = because it requires changes to
- NIC and Access Point firmware in = order to fix security bugs or
- add a  new authentication = method. The current intention is to
- move the authentication function = above the MAC layer in WEP v2.0.
-
- > What about 3G networks?
-
- I'm not familiar enough with the 3G = physical and data link proposals
- to give an opinion. But if 3G can = honor the IEEE 802 hard and soft
- invariants, then it is a candidate = for use of the IEEE 802.1 MAC,
- regardless of what the PHY = is.
-
- Hard invariants: Nonduplication, = Sequential delivery
- Soft invariants: Low delay, high = bandwidth, low error rate
-
- Note that 802.11 honors these = invariants even though it operates
- over the airwaves. The low error = rate soft invariant (and sequential
- delivery) is honored via ARQ, and = could conceivably be honored by
- other methods as well (e.g. = FEC).
-
- The "low delay" invariant = is relative; I've seen 802.11 installations with
- delay of > 200 ms that still = function. "High bandwidth" was said to apply
- to the initial 802.11 = implementations running at 1-2 Mbps, and I've seen
- applications using WAN mini-port = drivers (e.g. latest Metricom cards) run
- fine at 128 Kbps speeds. So = "high bandwidth"  is somewhat relative too.
-
- >Why not provide means of doing = this at a higher layer, for instance DHCP?
-
- I think that the architecture = issues (layer 3/4 vs. layer 2) should be kept
- separate from the = implementation  issues (DHCP vs. alternative protocols).
-
- We might decide that layer 3 or = layer 4 authentication makes sense in some
- cases, but that wouldn't = necessarily imply DHCP as a solution. I'm not fond
- of using authenticated DHCP for = access control because it wasn't
- developed to handle that scenario. = After all, since a host can always
- choose a static address, = authenticated DHCP by itself can't function as
- an access control mechanism. You = need another mechanism, such as layer 3
- filtering, in addition. See = comments below relating to state requirements.

3. I agree, DHCP was not meant for = access control. I don't even know how
one could do the same. What I see it = being useful for is as an initial access
and configuration protocol for = several types of access networks,
including the non-Ethernet = ones.

My point:
In some of the emerging access = networks both 802.11 and PPP may
not be suitable points for = authentication and interface to AAA, NOT
access control. DHCP with means for = interfacing to AAA presents itself as
an alternative for the function of = initial access and configuration of the
stack, thanks to its low = administrative costs and the fact that it is to
a large extent agnostic to the lower = layers.

-
- Since George has expressed = frustration that I always seem to be answering
- questions with more questions, I = thought I'd keep up the tradition ;)
-
- Here are the questions that you'd = need to answer in order to justify
- doing authentication at layer 3 or = above:
-
- 1. Is there a compelling reason to = invent a new MAC layer rather than just
- reusing PPP and IEEE 802?

Addressed above in 2.

-
- 2. Are we providing port access = control, machine access control or user
- access control? Note that this is a = separate issue from whether the
- identity claimed is that of a = machine, user or group.
-
- Port access control requires the = least state, since the maximum state
- required is in proportion to the = number of ports on the NAS.
-
- Machine access control requires = state for the maximum number of machines
- that can be connected to a NAS. If = the NAS supports LAN technologies, then
- the number of machines can be = considerably larger than the number of
- ports. For example, if we need to = authentication every node on a LAN
- at layer 3, we could end up with = thousands of nodes in the filter table;
- this could impact throughput and = increase cost.
-
- The state requirements for user = access control are even larger -- you could
- have multiple users per = machine.
-
- Since state implies more hardware = and higher cost as well as speed
- penalties, low cost/high speed = devices have tended to support only
- port-based access control, which is = the model implicitly assumed in
- PPP and 802.1X.

As pointed above in 3, I do not see = access control as a function of DHCP.

-
- 3. If authentication is done at = layer 3, how do we deal with multi-protocol
- support? I am not thinking of = AppleTalk, IPX, etc. so much as both IPv4 and
- IPv6. Do we have an authentication = per protocol, or can one authentication
- be
- done that applies to all protocols? = If authentication is done at layer 4,
- do we authenticate all = applications? If so, how would this differ from
- an application layer authentication = framework such as SASL?

I am advocating authentication for = initial access and configuration via
DHCP. Application (service) level = authentication is beyond the scope of an
initial access and configuration = protocol as is access control. As far as
the question about IPv4/v6 support = goes, the initial
configuration protocol (like = DHCPv4/v6) that is responsible for getting
the v4/v6 stacks up and running can = interface to AAA.

Cheers,
-- Roop
________________________________________





------_=_NextPart_001_01C0A26F.92D33A40-- From owner-dhcp-v4@bucknell.edu Thu Mar 1 13:07:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13700 for ; Thu, 1 Mar 2001 13:07:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21HurL00009; Thu, 1 Mar 2001 12:56:53 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f21HtCL29174 for ; Thu, 1 Mar 2001 12:55:13 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f21Hk5C02450; Thu, 1 Mar 2001 09:46:05 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Cc: "Bill Gage" Subject: RE: why authenticate with DHCP? Date: Thu, 1 Mar 2001 09:53:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01C0A235.86DBEBE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <13E2EF604DE5D111B2E50000F80824E806F2AE9C@zwdld001.ca.nortel.com> 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 This is a multi-part message in MIME format. ------=_NextPart_000_008B_01C0A235.86DBEBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Re: why authenticate with DHCP? > I agree, DHCP was not meant for access control. I don't even know how > one could do the same. > I am advocating authentication for initial access and configuration via > DHCP. Aren't these two statements in contradiction? If authenticated DHCP is not useful for access control, how can it be used for authentication for initial access? I understand how it can be used for configuration, though. In fact, DHCP can be used for configuration in any of the layer 2 schemes too, including PPP and 802.1X. ------=_NextPart_000_008B_01C0A235.86DBEBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: why authenticate with DHCP?
 > I agree, DHCP was not = meant for=20 access control. I don't even know how 
 > one could=20 do the same.  
 
 > I am advocating = authentication for=20 initial access and configuration via 
 > DHCP.  
 
Aren't these=20 two statements in contradiction? If authenticated DHCP=20 is
not useful for=20 access control, how can it be used for authentication=20 for
initial=20 access?
 
I understand=20 how it can be used for configuration, though. In fact,=20 DHCP
can be used=20 for configuration in any of the layer 2 schemes too,=20 including
PPP and=20 802.1X.
------=_NextPart_000_008B_01C0A235.86DBEBE0-- From owner-dhcp-v4@bucknell.edu Thu Mar 1 13:54:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16888 for ; Thu, 1 Mar 2001 13:54:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21IkRL07938; Thu, 1 Mar 2001 13:46:27 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f21IkBL18343 for ; Thu, 1 Mar 2001 13:46:11 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA21101; Thu, 1 Mar 2001 10:45:44 -0800 (PST) Message-Id: <4.1.20010301125838.00bf7730@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 01 Mar 2001 13:45:00 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: why authenticate with DHCP? Cc: "Bill Gage" In-Reply-To: <13E2EF604DE5D111B2E50000F80824E806F2AE9C@zwdld001.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 11:49 AM 03/01/2001 -0500, Biswaroop Mukherjee wrote: > >1. ... An interface to AAA can be created at several layers. >... If DHCP is to be used as an alternative [to PPP], >we need to address the issue of _interfacing_ to AAA. It seems that the question should be how to best interface the AA function, which might include (port) access control, with DHCP for configuration that might depend on attributes of the AA. >2. I would not presume to know about Ethernet being as pervasive as IP. >But I see your point that Token Ring, ATM, FDDI, ARCnet etc. are seen >less commonly. But I do see a proliferation of different physical media >and associated protocols (e.g., fiber and a whole bunch of wireless >protocols). Because the link layer is closer to the physical media as >opposed to the network layer and deals with things like framing, I >would not discount the possibility that non-Ethernet like protocols will >be used for these new physical layers and thus gain popularity. In fact >the advocates of UTRAN will tell you that there is indeed an enormous >market that is expected to use their networks and thus their >link layer protocols. Please give more details about UTRAN. A new link-layer protocol? Does it have any access control mechanism? >On Wed, 28 Feb 2001, Bernard Aboba wrote: >- IEEE 802.1X authentication occurs above the 802.1 MAC layer, which >- means that it can be used by any IEEE 802 technology, including >- Ethernet (802.3), Token Ring (802.5), FDDI (ANSI), WLAN (802.11), >- PAN (802.16), etc. >- >- In IEEE 802.11b, authentication occurs below the 802.1 MAC layer. >- That is, WEP v1.0 packets are not visible to a conventional >- sniffer operating in promiscuous mode, although special 802.11 >- sniffers can get at it. >- ... > >3. I agree, DHCP was not meant for access control... >What I see it being useful for is as an initial access and >configuration protocol for several types of access networks, >including the non-Ethernet ones. > >My point: >In some of the emerging access networks both 802.11 and PPP may >not be suitable points for authentication and interface to AAA, NOT >access control. DHCP with means for interfacing to AAA presents itself >as an alternative for the function of initial access and configuration >of the stack, thanks to its low administrative costs and the fact that >it is to a large extent agnostic to the lower layers. Ethernet and 802.11 are not the only cases. PPP has supported access control and initial configuration all along, while the 802 family has only recently had access control through 802.1x, with configuration still left to DHCP. Since 802.1x covers all 802 link-layer protocols, not just ethernet, we seem to now have access-control coverage of most (if not all) link layers that connect directly to hosts. (UTRAN?) >- Here are the questions that you'd need to answer in order to >- justify doing authentication at layer 3 or above: >- >- 1. Is there a compelling reason to invent a new MAC layer rather >- than just reusing PPP and IEEE 802? > >Addressed above in 2. But 2. above only speculates about future link-layer protocols that might be created for new physical layers. It might make more sense, now that all the 802-family link-layer protocols - not just ethernet - have access control available through 802.1x (not 802.11) to expect similar functionality from any new link layer proposed in the future. My impression is that a mechanism to coordinate between the AAA that is used for link-layer access control and the configuration by DHCP, providing the same capability that RFC 1332 provides for PPP, would be sufficient. John From owner-dhcp-v4@bucknell.edu Thu Mar 1 15:02:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20620 for ; Thu, 1 Mar 2001 15:02:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f21JsFL31641; Thu, 1 Mar 2001 14:54:15 -0500 (EST) 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 f21JrdL02826 for ; Thu, 1 Mar 2001 14:53:40 -0500 (EST) Received: from localhost (bmukherj@localhost) by styx.uwaterloo.ca (8.11.0/8.11.0) with ESMTP id f21Jpcn06138; Thu, 1 Mar 2001 14:51:38 -0500 Date: Thu, 1 Mar 2001 14:51:38 -0500 (EST) From: Roop Mukherjee To: DHCPv4 discussion list cc: DHCPv4 discussion list , Bill Gage Subject: RE: why authenticate with DHCP? In-Reply-To: Message-ID: 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 Allow me to clarify. On Thu, 1 Mar 2001, Bernard Aboba wrote: - > I agree, DHCP was not meant for access - control. I don't even know how - > one could do the same. - - > I am advocating authentication for initial access and configuration via - > DHCP. - - Aren't these two statements in contradiction? If authenticated DHCP is - not useful for access control, how can it be used for authentication for - initial access? Roughly, my idea of access control is not letting un-authorized people use the network. DHCP is used by the clients to send its first few packets to the network and ask for configuration. With authenticated DHCP the first few packets that ask for configuration would also present credentials that would be used to authenticate the user before sending him configuration information. Access control on the other hand, would involve network access points with filters etc. that keep packets from unauthorized users out. It is not that the initial authentication (which may be done by DHCP) and access control are unrelated. Indeed access regulator may use the information that a user has been authenticated and authorized for access from say AAA agents to configure its mechanisms (e.g. set parameters for filtering). What the first sentence says is, I cant see how an initial access protocol that carries credentials or configuration data can perform access control (i.e. keep rouge packets out) on its own. While the second sentence says that a protocol that is used to request configuration can involve the requestor presenting credentials and the resource server verifying them. For the purpose of this WG we are interested in the later. -- Roop ________________________________________ From owner-dhcp-v4@bucknell.edu Thu Mar 1 22:31:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04467 for ; Thu, 1 Mar 2001 22:31:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f223NSL15977; Thu, 1 Mar 2001 22:23:29 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f223LlL20037 for ; Thu, 1 Mar 2001 22:21:47 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f223Lki23791 for ; Thu, 1 Mar 2001 21:21:46 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f223LkU23684 for ; Thu, 1 Mar 2001 21:21:46 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 01 21:23:15 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 21:23:14 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69353E12@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Cc: pirozzi@cabletron.com Subject: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS Date: Thu, 1 Mar 2001 21:23:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A2C8.1D43B7B0" Reply-To: Bernie.Volz@am1.ericsson.se 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_001_01C0A2C8.1D43B7B0 Content-Type: text/plain; charset="iso-8859-1" Thomas (and others): I've included the (I believe) REAL original message for this thread on the ipcdn mailing list (from the archive at http://www.ietf.org/mail-archive/working-groups/ipcdn/current/maillist.html). If they are after current lease information, perhaps Rich Woundy and Kim Kinnear's DHCP Lease Query draft would address this (draft-ietf-dhc-leasequery-01.txt). It obviously isn't usable today as I don't believe anyone (except perhaps Cisco) has implemented it (I think Cisco's implementation is based on an earlier draft). This isn't done using SNMP but instead uses new DHCP message types. This also isn't necessarily what the leasequery draft was developed for. - Bernie Volz Here's the 'original' posting for this thread: -----Original Message----- From: Pirozzi, Timothy (Max Power) [mailto:pirozzi@cabletron.com] Sent: Wednesday, February 07, 2001 3:47 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS Hi All, I was looking at the DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS and I was looking for a fuctionality not mentioned by any of the traps currently listed. Here is the background: Currently, in a customer's cable modem deployment keeping track of a CM's IP is a nightmare. Every morning a list has to be retrieved from DHCP server and that is used to reorganised to what was in the snmp management system usually some type of model. This is a big concern to many ISPs I was wondering if there could be two more Traps added to the list of cm traps currently available. The first trap would say I (the CM) have just connected up and the DHCP gave me this IP. The second trap would say I (the CM) have just leasted a new IP from the DHCP server here is the OLD IP and here is the NEW IP. What does everyone think? Thanks Tim -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Thursday, March 01, 2001 9:14 AM To: DHCPv4 discussion list Subject: FWD: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS Can anyone here comment on how to do this? (please cc original author and/or ipcdn list). Thomas ------_=_NextPart_001_01C0A2C8.1D43B7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB DEFINITIONS

Thomas (and others):

I've included the (I believe) REAL original message = for this thread on the ipcdn mailing list (from the archive at http://www.ietf.org/mail-archive/working-groups/ipcdn/= current/maillist.html).

If they are after current lease information, perhaps = Rich Woundy and Kim Kinnear's DHCP Lease Query draft would address this = (draft-ietf-dhc-leasequery-01.txt). It obviously isn't usable today as = I don't believe anyone (except perhaps Cisco) has implemented it (I = think Cisco's implementation is based on an earlier draft). This isn't = done using SNMP but instead uses new DHCP message types. This also = isn't necessarily what the leasequery draft was developed = for.

- Bernie Volz

Here's the 'original' posting for this thread:

-----Original Message-----
From: Pirozzi, Timothy (Max Power) [mailto:pirozzi@cabletron.com]<= /FONT>
Sent: Wednesday, February 07, 2001 3:47 PM
To: 'ipcdn@ietf.org'
Subject: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB = DEFINITIONS


Hi All,

I was looking at the DOCS-CABLE-DEVICE-TRAP-MIB = DEFINITIONS
and I was looking for a fuctionality not mentioned = by any of
the traps currently listed.
Here is the background:

Currently, in a customer's cable modem deployment = keeping track
of a CM's IP is a nightmare. Every morning a list = has to be
retrieved from DHCP server and that is used to = reorganised to
what was in the snmp management system usually some = type of model.
This is a big concern to many ISPs

I was wondering if there could be two more Traps = added to the
list of cm traps currently available.

The first trap would say I (the CM) have just = connected
up and the DHCP gave me this IP. 

The second trap would say I (the CM) have just = leasted a new IP
from the DHCP server here is the OLD IP and here is = the NEW IP.



What does everyone think?



Thanks

Tim


-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com= ]
Sent: Thursday, March 01, 2001 9:14 AM
To: DHCPv4 discussion list
Subject: FWD: RE: [ipcdn] DOCS-CABLE-DEVICE-TRAP-MIB = DEFINITIONS


Can anyone here comment on how to do this? (please cc = original author
and/or ipcdn list).

Thomas

------_=_NextPart_001_01C0A2C8.1D43B7B0-- From owner-dhcp-v4@bucknell.edu Fri Mar 2 05:43:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25105 for ; Fri, 2 Mar 2001 05:43:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f22AbAL14740; Fri, 2 Mar 2001 05:37:10 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f22AawL03975 for ; Fri, 2 Mar 2001 05:36:58 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 05:36:43 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: "'aboba@internaut.com'" , "'gageb@nortelnetworks.com'" , "'jschnizl@cisco.com'" , "'bmukherj@styx.uwaterloo.ca'" Subject: RE: why authenticate with DHCP? Date: Fri, 2 Mar 2001 05:36:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi all, I have completely missed this discussion for some reason...Let me try to get back in...I would not want to miss a party :-) I am also tempted to copy BURP list but we are likely to hit the same people so I am refraining from doing so... I see that there is a certain momentum behind 802.X access control mechanisms and I definitely think it makes some sense to try and rely on such mechanisms given the leading role of 802 type link layers in the Internet today. I still find hard to come to terms, however, with the idea of preferring a Link Layer mechanism over a network layer mechanism when this mechanism (access control) is clearly needed across different link layers. And my argument boils down to two things: 1. Relying on 802.X means that 802 type link layers will be able to use the same mechanism. Moreover, we seam to imply that since 802 seams popular at the moment, all future Link Layers should also comply with it...I think that is dangerous and may limit the evolution of link layers and although some will say "who needs another link layer" I would argue that in the wireless world, there is a lot of room for innovation...we are basically just starting... 2. A meta argument that follows, is that of service integration. How would a service provider deploy a AAA system that works across all its Access Network offerings? It is clearly good that 802.X is using Radius (and I guess in the future Diameter) for AAA, giving integration capabilities. But each link layer, even if it is 802 based, may interface with AAA in slightly different way...and I would argue that, based on 1. above, 802 may not always cut it and thus break integration later on.... So, a network layer mechanism is always better or at least safer...since that is the point of the network layer...i.e.: provide the same function across different link layers...Since I will find hard to believe that anyone will disagree with that, the discussion seams to be around the question of how dominant 802 type link layers will be... Regards George -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Thursday, March 01, 2001 6:45 PM To: DHCPv4 discussion list Cc: Bill Gage Subject: Re: why authenticate with DHCP? At 11:49 AM 03/01/2001 -0500, Biswaroop Mukherjee wrote: > >1. ... An interface to AAA can be created at several layers. >... If DHCP is to be used as an alternative [to PPP], >we need to address the issue of _interfacing_ to AAA. It seems that the question should be how to best interface the AA function, which might include (port) access control, with DHCP for configuration that might depend on attributes of the AA. >2. I would not presume to know about Ethernet being as pervasive as IP. >But I see your point that Token Ring, ATM, FDDI, ARCnet etc. are seen >less commonly. But I do see a proliferation of different physical media >and associated protocols (e.g., fiber and a whole bunch of wireless >protocols). Because the link layer is closer to the physical media as >opposed to the network layer and deals with things like framing, I >would not discount the possibility that non-Ethernet like protocols will >be used for these new physical layers and thus gain popularity. In fact >the advocates of UTRAN will tell you that there is indeed an enormous >market that is expected to use their networks and thus their >link layer protocols. Please give more details about UTRAN. A new link-layer protocol? Does it have any access control mechanism? >On Wed, 28 Feb 2001, Bernard Aboba wrote: >- IEEE 802.1X authentication occurs above the 802.1 MAC layer, which >- means that it can be used by any IEEE 802 technology, including >- Ethernet (802.3), Token Ring (802.5), FDDI (ANSI), WLAN (802.11), >- PAN (802.16), etc. >- >- In IEEE 802.11b, authentication occurs below the 802.1 MAC layer. >- That is, WEP v1.0 packets are not visible to a conventional >- sniffer operating in promiscuous mode, although special 802.11 >- sniffers can get at it. >- ... > >3. I agree, DHCP was not meant for access control... >What I see it being useful for is as an initial access and >configuration protocol for several types of access networks, >including the non-Ethernet ones. > >My point: >In some of the emerging access networks both 802.11 and PPP may >not be suitable points for authentication and interface to AAA, NOT >access control. DHCP with means for interfacing to AAA presents itself >as an alternative for the function of initial access and configuration >of the stack, thanks to its low administrative costs and the fact that >it is to a large extent agnostic to the lower layers. Ethernet and 802.11 are not the only cases. PPP has supported access control and initial configuration all along, while the 802 family has only recently had access control through 802.1x, with configuration still left to DHCP. Since 802.1x covers all 802 link-layer protocols, not just ethernet, we seem to now have access-control coverage of most (if not all) link layers that connect directly to hosts. (UTRAN?) >- Here are the questions that you'd need to answer in order to >- justify doing authentication at layer 3 or above: >- >- 1. Is there a compelling reason to invent a new MAC layer rather >- than just reusing PPP and IEEE 802? > >Addressed above in 2. But 2. above only speculates about future link-layer protocols that might be created for new physical layers. It might make more sense, now that all the 802-family link-layer protocols - not just ethernet - have access control available through 802.1x (not 802.11) to expect similar functionality from any new link layer proposed in the future. My impression is that a mechanism to coordinate between the AAA that is used for link-layer access control and the configuration by DHCP, providing the same capability that RFC 1332 provides for PPP, would be sufficient. John From owner-dhcp-v4@bucknell.edu Fri Mar 2 06:52:59 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25964 for ; Fri, 2 Mar 2001 06:52:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f22BkWL23412; Fri, 2 Mar 2001 06:46:32 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f22BkNL00803 for ; Fri, 2 Mar 2001 06:46:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25670; Fri, 2 Mar 2001 06:46:21 -0500 (EST) Message-Id: <200103021146.GAA25670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-concat-00.txt Date: Fri, 02 Mar 2001 06:46:21 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Encoding Long DHCP Options Author(s) : T. Lemon Filename : draft-ietf-dhc-concat-00.txt Pages : Date : 01-Mar-01 This draft specifies how DHCP options in a DHCP packet can be aggregated so that DHCP protocol agents can send options that are more than 255 bytes in length. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-concat-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-concat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-concat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010301141343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-concat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-concat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141343.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 2 06:53:22 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26058 for ; Fri, 2 Mar 2001 06:53:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f22BmYL12545; Fri, 2 Mar 2001 06:48:34 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f22BkSL12361 for ; Fri, 2 Mar 2001 06:46:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25686; Fri, 2 Mar 2001 06:46:26 -0500 (EST) Message-Id: <200103021146.GAA25686@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-csr-04.txt Date: Fri, 02 Mar 2001 06:46:26 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Classless Static Route Option for DHCP Author(s) : T. Lemon Filename : draft-ietf-dhc-csr-04.txt Pages : Date : 01-Mar-01 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-csr-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-csr-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010301141352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-csr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-csr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Mar 2 08:48:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29222 for ; Fri, 2 Mar 2001 08:48:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f22Dg4L15471; Fri, 2 Mar 2001 08:42:04 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f22DfmL17977 for ; Fri, 2 Mar 2001 08:41:48 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id FAA09131; Fri, 2 Mar 2001 05:41:29 -0800 (PST) Message-Id: <4.1.20010302082104.00ad52d0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 02 Mar 2001 08:41:18 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: RE: why authenticate with DHCP? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 05:36 AM 03/02/2001 -0500, George Tsirtsis wrote: >... to copy BURP list but we are likely to hit the same people BURP might have other interests than coordinating AAA with the initial configuration of a host. >I see that there is a certain momentum behind 802.X access control >mechanisms and I definitely think it makes some sense to try and rely on >such mechanisms given the leading role of 802 type link layers in the >Internet today. 802.1x provides port-level access control based on Internet-Standard AAA which is comparable to the port-level access control for PPP. The conjecture is that these two cover most (if not all) host-connected link layers. If there are others now existing, it would help to know them. >I still find hard to come to terms, however, with the idea of preferring a >Link Layer mechanism over a network layer mechanism when this mechanism >(access control) is clearly needed across different link layers. And my >argument boils down to two things: > >1. Relying on 802.X means that 802 type link layers will be able to use the >same mechanism. Moreover, we seam to imply that since 802 seams popular at >the moment, all future Link Layers should also comply with it...I think that >is dangerous and may limit the evolution of link layers and although some >will say "who needs another link layer" I would argue that in the wireless >world, there is a lot of room for innovation...we are basically just >starting... I never intended to rely exclusively on 802 link layers and 802.1x. My suspicion is that PPP will be around for a long time. The point is that both of these use (or will as soon as ratified ;-) the Internet-Standard AAA server for authentication. The convergence implied in this approach is a GOOD THING. Now that even the 802-family of link-layers have included authenticated port-level access control, it would be reasonable to expect new link layers (especially wireless ones lacking physical access control) to perform similar functions. There is no intention to stifle innovation. >2. A meta argument that follows, is that of service integration. How would >a service provider deploy a AAA system that works across all its Access >Network offerings? It is clearly good that 802.X is using Radius (and I >guess in the future Diameter) for AAA, giving integration capabilities. But >each link layer, even if it is 802 based, may interface with AAA in slightly >different way...and I would argue that, based on 1. above, 802 may not >always cut it and thus break integration later on.... If each link layer provides a mechanism for the user to authenticate through the host and its local connection, it makes sense to pass the identity along for use in initial host configuration. Notice that this configuration includes the IP (layer-3) address, without which no network or higher layer communication occurs. >So, a network layer mechanism is always better or at least safer...since >that is the point of the network layer...i.e.: provide the same function >across different link layers...Since I will find hard to believe that anyone >will disagree with that, the discussion seams to be around the question of >how dominant 802 type link layers will be... The use of the authentication that is used in the link layer for initial configuration does not preclude other higher-layer authentications once IP connectivity is possible. Many applications will require their own authentication, and may or may not be integrated with AAA. John From owner-dhcp-v4@bucknell.edu Fri Mar 2 14:03:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13053 for ; Fri, 2 Mar 2001 14:03:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f22IsQL15201; Fri, 2 Mar 2001 13:54:26 -0500 (EST) 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 f22IsDL01291 for ; Fri, 2 Mar 2001 13:54:16 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id KAA21367; Fri, 2 Mar 2001 10:53:56 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00562; Fri, 2 Mar 01 11:14:40 -0800 Date: Fri, 2 Mar 2001 11:14:39 -0800 (GMT-0800) From: "Bernard D. Aboba" To: DHCPv4 discussion list Cc: DHCPv4 discussion list , "'gageb@nortelnetworks.com'" , "'jschnizl@cisco.com'" , "'bmukherj@styx.uwaterloo.ca'" Subject: RE: why authenticate with DHCP? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > 1. Relying on 802.X means that 802 type link layers will be able to use the > same mechanism. Moreover, we seem to imply that since 802 seams popular at > the moment, all future Link Layers should also comply with it. Remember, IEEE 802 is not a single technology, it is a family of link layers with considerable diversity. And "popular at the moment" seems to imply that IEEE 802 technology is a passing fad, when in fact it seems more likely that IEEE 802 will outlast IPv4. > I would argue that in the wireless > world, there is a lot of room for innovation...we are basically just > starting... I was just curious to understand some of the logic that is driving the evolution of wireless link layers. In many cases, wireless links do indeed use PPP or 802 framing. Are there specific reasons why these choices would not prove satisfactory in some cases? > 2. A meta argument that follows, is that of service integration. How would > a service provider deploy a AAA system that works across all its Access > Network offerings? It's very important to understand the AAA extensibility model, and why we've had such trouble accomodating DHCP and MIP, while extension to new link layers like VPN, ADSL, and 802 have been easy. AAA protocols support extensibility via addition of AVPs and attribute values. This is how RADIUS, which was created for dialup, has been able to be used in ADSL, VPNs, 802, etc. without any changes to the protocol. However, in the process, the assumption is that the AAA server does not actually need to add any code, only dictionary changes. This means that the AAA server MUST NOT be required to understand any details of the protocols that occur on the wire between the client and NAS. This critical assumption is broken if the AAA server is required to understand a new PDU type (such as parsing a DHCP or MIP registration message). This is why it is so hard for AAA to integrate with protocols that utilize a Message Integrity Check (MIC) that needs to be verified by AAA. The problem is that the AAA implementation then needs to have a copy of the entire packet to verify the MIC -- which requires the AAA server to parse the packet. This breaks the AAA architectural model. > each link layer, even if it is 802 based, may interface with AAA in slightly > different way... One of the major design points of AAA is to be able to handle new link layers with no changes to the protocol, only changes to the dictionary. That way these new access methods can be accomodated without code changes. Of the extensions, ADSL and 802 integration have been the most successful -- being accomplished without requiring new AVPs, only new attribute values. VPN integration was somewhat less successful, since the "tags" required were not supported well on some implementations, requiring dictionary code changes. But even there, no protocol changes were required, and no adjustment to the AAA architectural model. > always cut it and thus break integration later on.... As described early, the only thing that can "break integration" is changing the AAA architectural model, such as by requiring that it integrate with other protocols, thereby requiring large implementation changes. This is one of my issues with the DHCP/AAA integration proposal -- it would require the AAA server to understand DHCP, in order to be able to sign the authenticated DHCP packets. The alternative, which is to use challenge/response authentication, does not satisfy the authenticated DHCP security requirements since it would not integrity protect the packet. > So, a network layer mechanism is always better or at least safer... Experience has told us that the biggest AAA integration problems actually occur with network-layer authentication methods that require integrity protection, such as authenticated DHCP and Mobile IP. Far from being "safe", this kind of integration has proven to take years to work through, changes in the fundamental AAA architecture, etc. Meanwhile, changes for new link layers have been relatively trivial. From owner-dhcp-v4@bucknell.edu Sat Mar 3 09:06:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19357 for ; Sat, 3 Mar 2001 09:06:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f23E0KL13397; Sat, 3 Mar 2001 09:00:20 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f23E0CL03400 for ; Sat, 3 Mar 2001 09:00:12 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Sat, 3 Mar 2001 08:59:56 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Cc: "'DHCPv4 discussion list '" , "''gageb@nortelnetworks.com' '" , "''jschnizl@cisco.com' '" , "''bmukherj@styx.uwaterloo.ca' '" Subject: RE: why authenticate with DHCP? Date: Sat, 3 Mar 2001 08:59:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----Original Message----- From: Bernard D. Aboba To: George Tsirtsis Cc: DHCPv4 discussion list; 'gageb@nortelnetworks.com'; 'jschnizl@cisco.com'; 'bmukherj@styx.uwaterloo.ca' Sent: 02/03/01 14:14 Subject: RE: why authenticate with DHCP? > 1. Relying on 802.X means that 802 type link layers will be able to use the > same mechanism. Moreover, we seem to imply that since 802 seams popular at > the moment, all future Link Layers should also comply with it. Remember, IEEE 802 is not a single technology, it is a family of link layers with considerable diversity. And "popular at the moment" seems to imply that IEEE 802 technology is a passing fad, when in fact it seems more likely that IEEE 802 will outlast IPv4. GT> Well, yes...:-) although I did not mean that 802 may soon go away but rather that other, non-802 technologies, may also become important in the future. > I would argue that in the wireless > world, there is a lot of room for innovation...we are basically just > starting... I was just curious to understand some of the logic that is driving the evolution of wireless link layers. In many cases, wireless links do indeed use PPP or 802 framing. Are there specific reasons why these choices would not prove satisfactory in some cases? GT> Is it only framing we are talking about? Wireless data is a whole new game...There is no widely (cellular scale) deployed wireless link layer today that can cope with data speeds of more than a few Kbits/sec in an economic, scalable and elegant way and...I would not hold my breath for 3G to solve this problem since these are basically voice technologies adapted to run data, while the likes of wavelan are not bad but they are spectrally inefficient....I argue that wireless data is likely to produce some new link layers as we go ahead...whether 802/PPP framing is going to be good enough for them I could not say for sure...but that is the point.... > 2. A meta argument that follows, is that of service integration. How would > a service provider deploy a AAA system that works across all its Access > Network offerings? It's very important to understand the AAA extensibility model, and why we've had such trouble accomodating DHCP and MIP, while extension to new link layers like VPN, ADSL, and 802 have been easy. AAA protocols support extensibility via addition of AVPs and attribute values. This is how RADIUS, which was created for dialup, has been able to be used in ADSL, VPNs, 802, etc. without any changes to the protocol. GT> I understand. However, in the process, the assumption is that the AAA server does not actually need to add any code, only dictionary changes. This means that the AAA server MUST NOT be required to understand any details of the protocols that occur on the wire between the client and NAS. GT> Agreed. This critical assumption is broken if the AAA server is required to understand a new PDU type (such as parsing a DHCP or MIP registration message). GT> I understand and I never suggested that...did you think I did? This is why it is so hard for AAA to integrate with protocols that utilize a Message Integrity Check (MIC) that needs to be verified by AAA. The problem is that the AAA implementation then needs to have a copy of the entire packet to verify the MIC -- which requires the AAA server to parse the packet. This breaks the AAA architectural model. GT> Just to make sure we are on the same page, what I suggested for DHCP is exactly (triggering AAA at the DHCP RA) should work exactly the same with PPP as far as AAA is concern. DHCP does not directly talk to AAA servers (as PPP doesn't), it just carries the elements that the AAA client needs to put in AVP pairs and send them to the AAA server. > each link layer, even if it is 802 based, may interface with AAA in slightly > different way... One of the major design points of AAA is to be able to handle new link layers with no changes to the protocol, only changes to the dictionary. That way these new access methods can be accomodated without code changes. Of the extensions, ADSL and 802 integration have been the most successful -- being accomplished without requiring new AVPs, only new attribute values. VPN integration was somewhat less successful, since the "tags" required were not supported well on some implementations, requiring dictionary code changes. But even there, no protocol changes were required, and no adjustment to the AAA architectural model. GT> I agree but all these new link layers require their own link layer trasport of user authentication/identity between the end node and wherever the AAA client leaves...A network layer transport would work on top of any link layer in exactly the same way... > always cut it and thus break integration later on.... As described early, the only thing that can "break integration" is changing the AAA architectural model, such as by requiring that it integrate with other protocols, thereby requiring large implementation changes. This is one of my issues with the DHCP/AAA integration proposal -- it would require the AAA server to understand DHCP, in order to be able to sign the authenticated DHCP packets. The alternative, which is to use challenge/response authentication, does not satisfy the authenticated DHCP security requirements since it would not integrity protect the packet. GT> Well, we do seam to have a disconnect here...As I said, I never suggested the AAA server should understand DHCP...but I might be missing your point about integrity protection in relation to this... I will have to go and have a look at the DHCP auth. req. draft...as I sain before I am not a security expert...which makes me wonder why am I in the middle of a security discussion ;-0 :) Regards George From owner-dhcp-v4@bucknell.edu Sat Mar 3 15:11:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24414 for ; Sat, 3 Mar 2001 15:11:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f23K50L20780; Sat, 3 Mar 2001 15:05:00 -0500 (EST) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f23K4lL03767 for ; Sat, 3 Mar 2001 15:04:48 -0500 (EST) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id CF859970; Sat, 3 Mar 2001 12:06:38 -0800 (PST) Received: from exccup-gh02.cac.cpqcorp.net (exccup-gh02.cac.cpqcorp.net [16.105.248.61]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id C48DF81B for ; Sat, 3 Mar 2001 12:06:38 -0800 (PST) Received: by exccup-gh02.cac.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Sat, 3 Mar 2001 12:04:31 -0800 Message-ID: <2BAEE918EF6CD1118FA800805F57F12E0B1500C4@excaus-11601.txn.cpqcorp.net> From: "Manpuria, Aditya" To: DHCPv4 discussion list Subject: A question on Infinite leases Date: Sat, 3 Mar 2001 12:04:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Aditya.Manpuria@compaq.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, Is it necessary for a DHCP server to be able to support inifinite leases in order to claim compliance with the DHCP standards. I went through RFC2131 and found the following - ---------------------------------------------------------------------------- ------ 2. Protocol Summary DHCP defines mechanisms through which clients can be assigned a network address for a finite lease, allowing for serial reassignment of network addresses to different clients. 2.2 Dynamic allocation of network addresses The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the client has been retired. 3.3 Interpretation and representation of time values A client acquires a lease for a network address for a fixed period of time (which may be infinite). Throughout the protocol, times are to be represented in units of seconds. The time value of 0xffffffff is reserved to represent "infinity". --------------------------------------------------------------------------- The RFC does not state whether it is a MUST/MAY for a DHCP server to be able to hand out infinite leases. On one hand, the RFC describes DHCP as a mechanism of providing finite-leased IP addresses whereas on the other it has provisions for inifinite leases as well. Could someone please guide me on this issue. Thanks, Aditya. From owner-dhcp-v4@bucknell.edu Mon Mar 5 03:27:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08753 for ; Mon, 5 Mar 2001 03:27:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f258KAL10669; Mon, 5 Mar 2001 03:20:10 -0500 (EST) Received: from charon.cargill.com (charon.cargill.com [167.136.225.225]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f258K0L07460 for ; Mon, 5 Mar 2001 03:20:00 -0500 (EST) Received: from hermes.cargill.com (hermes.cargill.com [167.136.226.140]) by charon.cargill.com (8.8.8/8.8.8) with ESMTP id CAA15208 for ; Mon, 5 Mar 2001 02:19:44 -0600 (CST) From: Henk_Remijn@cargill.com Received: from berg.cgo.cargill.com (avocdc01.admin.cargill.com [167.136.226.136]) by hermes.cargill.com (8.8.8/8.8.8) with ESMTP id CAA14241 for ; Mon, 5 Mar 2001 02:19:42 -0600 (CST) Received: from localhost (root@localhost) by berg.cgo.cargill.com (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA54816 for ; Mon, 5 Mar 2001 09:19:39 +0100 (NFT) X-OpenMail-Hops: 1 Date: Mon, 5 Mar 2001 09:19:35 +0100 Message-Id: Subject: xx MIME-Version: 1.0 To: DHCPv4 discussion list Content-Type: multipart/alternative; boundary=openmail-part-028223d7-00000002 Reply-To: Henk_Remijn@cargill.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --openmail-part-028223d7-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline; filename="BDY.RTF" ;Creation-Date="Mon, 5 Mar 2001 09:19:34 +0100" Content-Transfer-Encoding: quoted-printable help --openmail-part-028223d7-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Mon, 5 Mar 2001 09:19:34 +0100" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYw XGZzd2lzc1xmY2hhcnNldDAgQXJpYWw7fX0NClx2aWV3a2luZDRcdWMxXHBhcmRcZjBcZnMy MCBoZWxwXHBhcg0KfQ0KAA== --openmail-part-028223d7-00000002-- From owner-dhcp-v4@bucknell.edu Mon Mar 5 06:48:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11526 for ; Mon, 5 Mar 2001 06:48:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f25BfxL20849; Mon, 5 Mar 2001 06:41:59 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f25BfrL03695 for ; Mon, 5 Mar 2001 06:41:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10541; Mon, 5 Mar 2001 06:41:51 -0500 (EST) Message-Id: <200103051141.GAA10541@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-17.txt Date: Mon, 05 Mar 2001 06:41:50 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, R. Droms Filename : draft-ietf-dhc-dhcpv6-17.txt Pages : 57 Date : 02-Mar-01 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-17.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302131434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302131434.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Mar 5 06:48:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11559 for ; Mon, 5 Mar 2001 06:48:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f25Bj3L09158; Mon, 5 Mar 2001 06:45:03 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f25BhTL00040 for ; Mon, 5 Mar 2001 06:43:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10796; Mon, 5 Mar 2001 06:43:26 -0500 (EST) Message-Id: <200103051143.GAA10796@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list CC: mobile-ip@sunroof.eng.sun.com, dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-glass-mobileip-agent-dhcp-proxy-01.txt Date: Mon, 05 Mar 2001 06:43:26 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP Agents as DHCP Proxies Author(s) : S. Glass Filename : draft-glass-mobileip-agent-dhcp-proxy-01.txt Pages : 21 Date : 02-Mar-01 Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-glass-mobileip-agent-dhcp-proxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302131744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-glass-mobileip-agent-dhcp-proxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302131744.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Mar 6 05:52:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06518 for ; Tue, 6 Mar 2001 05:52:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f26Ak6L07510; Tue, 6 Mar 2001 05:46:06 -0500 (EST) Received: from charon.cargill.com (charon.cargill.com [167.136.225.225]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f26Ak1L15271 for ; Tue, 6 Mar 2001 05:46:01 -0500 (EST) Received: from hermes.cargill.com (hermes.cargill.com [167.136.226.140]) by charon.cargill.com (8.8.8/8.8.8) with ESMTP id EAA18146 for ; Tue, 6 Mar 2001 04:45:41 -0600 (CST) From: Henk_Remijn@cargill.com Received: from berg.cgo.cargill.com (avocdc01.admin.cargill.com [167.136.226.136]) by hermes.cargill.com (8.8.8/8.8.8) with ESMTP id EAA04849 for ; Tue, 6 Mar 2001 04:45:40 -0600 (CST) Received: from localhost (root@localhost) by berg.cgo.cargill.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA35164 for ; Tue, 6 Mar 2001 11:45:38 +0100 (NFT) X-OpenMail-Hops: 1 Date: Tue, 6 Mar 2001 11:45:33 +0100 Message-Id: Subject: I want to unsubscribe MIME-Version: 1.0 To: DHCPv4 discussion list Content-Type: multipart/alternative; boundary=openmail-part-0282ca65-00000002 Reply-To: Henk_Remijn@cargill.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --openmail-part-0282ca65-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline; filename="BDY.RTF" ;Creation-Date="Tue, 6 Mar 2001 11:45:28 +0100" Content-Transfer-Encoding: quoted-printable Help. Someone know how to get rid of these mails. Why is admin info not included in the messages? --openmail-part-0282ca65-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Tue, 6 Mar 2001 11:45:28 +0100" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYw XGZzd2lzc1xmY2hhcnNldDAgQXJpYWw7fX0NClx2aWV3a2luZDRcdWMxXHBhcmRcZjBcZnMy MCBIZWxwLiBTb21lb25lIGtub3cgaG93IHRvIGdldCByaWQgb2YgdGhlc2UgbWFpbHMuIFdo eSBpcyBhZG1pbiBpbmZvIG5vdCBpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZXM/XHBhcg0KfQ0K AA== --openmail-part-0282ca65-00000002-- From owner-dhcp-v4@bucknell.edu Tue Mar 6 07:12:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08856 for ; Tue, 6 Mar 2001 07:12:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f26C5iL17035; Tue, 6 Mar 2001 07:05:44 -0500 (EST) 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 f26C5gL24068 for ; Tue, 6 Mar 2001 07:05:42 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA23961; Tue, 6 Mar 2001 07:05:23 -0500 (EST) Message-Id: <4.3.2.7.2.20010306070421.00b887a8@mail.bucknell.edu> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Mar 2001 07:05:14 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: I want to unsubscribe Cc: DHCPv4 discussion list In-Reply-To: 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 To leave the dhcp-v4 mailing list, please send mail to listproc@bucknell.edu containing the message: unsubscribe dhcp-v4 - Ralph Droms At 11:45 AM 3/6/2001 +0100, Henk_Remijn@cargill.com wrote: >Help. Someone know how to get rid of these mails. Why is admin info not >included in the messages? From owner-dhcp-v6@bucknell.edu Tue Mar 6 14:04:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22618; Tue, 6 Mar 2001 14:04:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f26J0BL22160; Tue, 6 Mar 2001 14:00:11 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f26J01L03615 for ; Tue, 6 Mar 2001 14:00:01 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26Ixtg09648 for ; Tue, 6 Mar 2001 12:59:59 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Mar 2001 12:59:55 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 12:59:54 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Cc: Jim.Bound@nokia.com Subject: DHCPv6 is really needed Date: Tue, 6 Mar 2001 12:59:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Folks, The attached specs all require DHCPv6. In addition it appears now Stateful IPv6 Autoconfiguration is taking on many new needs. Two key examples are that 3GPP and Optical Access Networks at the Customer Premise will both need DHCPv6 to configure addresses and provide other parameters. DHCPv6 will show up in those respective standards bodies out of the IETF too along with the other IETF IPv6 specifications. We really need to ship a first cut completed spec to get Proposed Standard status and get implementations moving. The market is ready. draft-ietf-ngtrans-dstm-04.txt draft-ietf-ngtrans-dstmext1-aiih-00.txt draft-ietf-ngtrans-siit-dstm-00.txt draft-shin-dstm-single-ipv4-00.txt draft-tsao-mobileip-dualstack-model-02.txt draft-dupont-mipv6-aaa-00.txt draft-ietf-ngtrans-v4-over-mipv6-00.txt regards, /jim From owner-dhcp-v4@bucknell.edu Tue Mar 6 15:07:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25567 for ; Tue, 6 Mar 2001 15:07:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f26K0SL24608; Tue, 6 Mar 2001 15:00:28 -0500 (EST) Received: from firewall.ma.virata.com (agranat.com [198.113.147.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f26K0LL18363 for ; Tue, 6 Mar 2001 15:00:21 -0500 (EST) Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id OAA19976 for ; Tue, 6 Mar 2001 14:59:44 -0500 Received: from localhost.localdomain (IDENT:root@dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.9.3/8.9.3) with ESMTP id OAA07698 for ; Tue, 6 Mar 2001 14:59:43 -0500 Received: (from worley@localhost) by localhost.localdomain (8.11.0/8.8.7) id f26JxhS10026; Tue, 6 Mar 2001 14:59:43 -0500 Date: Tue, 6 Mar 2001 14:59:43 -0500 Message-Id: <200103061959.f26JxhS10026@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: worley set sender to dworley@virata.com using -f To: DHCPv4 discussion list In-reply-to: <2BAEE918EF6CD1118FA800805F57F12E0B1500C4@excaus-11601.txn.cpqcorp.net> (Aditya.Manpuria@compaq.com) Subject: Re: A question on Infinite leases References: <2BAEE918EF6CD1118FA800805F57F12E0B1500C4@excaus-11601.txn.cpqcorp.net> From: worley@agranat.com 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: "Manpuria, Aditya" Is it necessary for a DHCP server to be able to support inifinite leases in order to claim compliance with the DHCP standards. I do not know if it is stated explicitly in the RFC, but the server has final authority over all aspects of the leases. So, from the protocol point of view, a server need not support infinite leases, since the client is not guaranteed that it can obtain an infinite lease even if it requests one. (From the point of view of the interface between the administrator and the server, it may or may not be possible to configure the server to give out infinite leases, but my belief is that that is outside the scope of the RFC.) Dale -- Dale R. WORLEY Project Manager - UPnP Virata Corp. Applications Infrastructure http://emweb.com From owner-dhcp-v6@bucknell.edu Tue Mar 6 17:00:45 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00124; Tue, 6 Mar 2001 17:00:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f26LumL03475; Tue, 6 Mar 2001 16:56:48 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f26LuWL06841 for ; Tue, 6 Mar 2001 16:56:33 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f26Ls9G03952 for ; Tue, 6 Mar 2001 16:54:09 -0500 Message-Id: <200103062154.f26Ls9G03952@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: Issue from San Diego IETF - temporary addresses In-Reply-To: Message from "Bernie Volz (EUD)" of "Mon, 19 Feb 2001 15:08:48 CST." <66F66129A77AD411B76200508B65AC691F6464@eambunt705.ena-east.ericsson.se> Date: Tue, 06 Mar 2001 16:54:09 -0500 From: Thomas Narten 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 > Narten also raised issue of interaction between DHCP and temporary > addresses. DHCP server can provide temporary addresses by assigning > addresses with short lifetimes. However, there will be an API > through which an application can request a temporary address. How > can the DHCP server indicate to the client which addresses are to be > "temporary" and which are "permanent"? Narten thinks IESG will > bounce anything that doesn't deal with temporary addresses. He will > develop requirements doc so WG can develop solution. Let me try to summarize the issues. The IPv6 architecture now support the notion of temporary addresses. Temporary addresses are normal addresses, i.e., they can be used just like other IPv6 addresses. However, they are designed to be used in cases where the TCP connection doesn't last forever, i.e., is "short" where short can mean a few seconds to minutes to hours. It does not mean for weeks or months. I.e., RFC 3041 suggests that a temporary address be 'preferred' for one day, and become invalid after a week. So its really intended for connections that don't last very long. Also, temporary addresses are intended to be uses by applications/devices that don't want to expose their (permanent) interface identifier to remote sites. There is a need for an API so that applications can indicate if they want to use a temporary vs. a "public" address, i.e., one that that doesn't change (or at least, doesn't change until there is a renumbering event, etc.). That is still a TBD item in IPNG and is not something this WG needs to worry about too much. For nodes using stateless autoconfiguration, RFC 3041 describes how temporary addresses are created, when they expire, etc. DHCPv6, because it can also be used to assign addresses to nodes, needs to have a story on temporary addresses. That is, a node should be able to use temporary addresses regardless of whether stateless or stateful address autoconfiguration is needed. Thus, the DHCPv6 spec needs to say how temporary addresses are created and/or assigned when DHCPv6 is used. Note that RFC 3041 makes it clear which addresses are "temporary" and which are not, and the address selection document draft-ietf-ipngwg-default-addr-select-02.txt makes recommendations on what to do with temporary addresses. I.e., it is a property of the address whether it is temporary or not, and that property is exploited in other parts of the IPv6 architecture. So I believe what DHCPv6 needs to do is define the mechanics for how temporary addresses are assigned to nodes. > Shouldn't this say "How can the DHCP client indicate to the server > which addreses are to be "temporary" and which are "permanent"? It > is after all the client that might have an understanding of how long > the address is desired. I would turn it around. One possible way of providing temporary address support in DHCP is to allow (require?) that the client request (via DHCP) that it wants temporary address(es) in addition to regular addresses. Note I am not saying the client says how many or anything other than "it does want temporary addresses". The DHCP server then *could* return a set of addresses, with the temporary addresses flagged with a special indication so that the client knows they are temporary (this is needed for the address selection rules mentioned earlier). > As the client will send an "Identity Association Option" to request > address(es), couldn't this simply be communicated via a lease > request time? Though there probably is no good field to store this > in. I don't think you want to overload lease time for this purpose. Temporary addresses are semantically different than addresses with a short lease. > And, then we should perhaps ask WHY DOES THE SERVER CARE? If the > client wants a short lease, the server simply grants it the > address(es) for however long the server policy dictates. If the > client doesn't want to use the address after a period of time, it is > ALWAYS able to RELEASE it whenever it is done. Even if it doesn't > release it but instead simply lets it expire, what's the harm? There > should be plenty of addresses available in IPv6. The client doesn't just want a short lease. It wants a temporary address (in addition to a public address). When its current temporary address expires, it will want to get a new one that is different than the one it had before. If the client just requested a new address with shorter lease, it might just get back the one it just had, which defeats the reason for having temporary addresses. > Of course, the requirements document might help answer why Thomas > feels there is a need to have a mechanism to explicitly request > these temporary addresses. Perhaps the reason for the 'temporary' > addresses is that they are supposed to be 'random' instead of based > on the EUI-64 identifier of the client; but as a previous message > pointed out nothing has been said as to how a DHCP server will > assign addresses. Not random, but changing over time and not to be reused in a predictable way. Thomas From owner-dhcp-v6@bucknell.edu Tue Mar 6 18:27:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03059; Tue, 6 Mar 2001 18:26:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f26NOKL01314; Tue, 6 Mar 2001 18:24:20 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f26NO7L18000 for ; Tue, 6 Mar 2001 18:24:07 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f26NO5g16579 for ; Tue, 6 Mar 2001 17:24:05 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Mar 2001 17:24:05 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 17:24:04 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Issue from San Diego IETF - temporary addresses Date: Tue, 6 Mar 2001 17:24:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Thomas, There is no way to differentiate a temp addr from other addr semantically. Please give us an example I don't see this in src addr select at all. In fact there are no bits in IPv6 addr arch anywhere to support this. Putting on my IPv6 hat I got to say that your statement that temporary addresses are part of the IPv6 address architecture is NOT TRUE. Its an appeasement for paranoids. There is nothing in stateless addr conf or ND or anywhere to do something special for IPv6 addresses. So I object to you putting that on this WG and DHCPv6 unless you can be more clear on showing consistency elsewhere. Also src addr select does not have consensus and a few folks (including me) will object at IESG last call and make issues if some things are not fixed in that spec. regards, /jim > -----Original Message----- > From: ext Thomas Narten [mailto:narten@RALEIGH.IBM.COM] > Sent: Tuesday,March 06,2001 4:54 PM > To: DHCPv6 discussion list > Subject: Re: Issue from San Diego IETF - temporary addresses > > > > Narten also raised issue of interaction between DHCP and temporary > > addresses. DHCP server can provide temporary addresses by assigning > > addresses with short lifetimes. However, there will be an API > > through which an application can request a temporary address. How > > can the DHCP server indicate to the client which addresses are to be > > "temporary" and which are "permanent"? Narten thinks IESG will > > bounce anything that doesn't deal with temporary addresses. He will > > develop requirements doc so WG can develop solution. > > Let me try to summarize the issues. The IPv6 architecture now support > the notion of temporary addresses. Temporary addresses are normal > addresses, i.e., they can be used just like other IPv6 > addresses. However, they are designed to be used in cases where the > TCP connection doesn't last forever, i.e., is "short" where short can > mean a few seconds to minutes to hours. It does not mean for weeks or > months. I.e., RFC 3041 suggests that a temporary address be > 'preferred' for one day, and become invalid after a week. So its > really intended for connections that don't last very long. Also, > temporary addresses are intended to be uses by applications/devices > that don't want to expose their (permanent) interface identifier to > remote sites. > > There is a need for an API so that applications can indicate if they > want to use a temporary vs. a "public" address, i.e., one that that > doesn't change (or at least, doesn't change until there is a > renumbering event, etc.). That is still a TBD item in IPNG and is not > something this WG needs to worry about too much. > > For nodes using stateless autoconfiguration, RFC 3041 describes how > temporary addresses are created, when they expire, etc. DHCPv6, > because it can also be used to assign addresses to nodes, needs to > have a story on temporary addresses. That is, a node should be able to > use temporary addresses regardless of whether stateless or stateful > address autoconfiguration is needed. Thus, the DHCPv6 spec needs to > say how temporary addresses are created and/or assigned when DHCPv6 is > used. > > Note that RFC 3041 makes it clear which addresses are "temporary" and > which are not, and the address selection document > draft-ietf-ipngwg-default-addr-select-02.txt makes recommendations on > what to do with temporary addresses. I.e., it is a property of the > address whether it is temporary or not, and that property is exploited > in other parts of the IPv6 architecture. So I believe what DHCPv6 > needs to do is define the mechanics for how temporary addresses are > assigned to nodes. > > > Shouldn't this say "How can the DHCP client indicate to the server > > which addreses are to be "temporary" and which are "permanent"? It > > is after all the client that might have an understanding of how long > > the address is desired. > > I would turn it around. One possible way of providing temporary > address support in DHCP is to allow (require?) that the client request > (via DHCP) that it wants temporary address(es) in addition to regular > addresses. Note I am not saying the client says how many or anything > other than "it does want temporary addresses". The DHCP server then > *could* return a set of addresses, with the temporary addresses > flagged with a special indication so that the client knows they are > temporary (this is needed for the address selection rules mentioned > earlier). > > > As the client will send an "Identity Association Option" to request > > address(es), couldn't this simply be communicated via a lease > > request time? Though there probably is no good field to store this > > in. > > I don't think you want to overload lease time for this > purpose. Temporary addresses are semantically different than addresses > with a short lease. > > > And, then we should perhaps ask WHY DOES THE SERVER CARE? If the > > client wants a short lease, the server simply grants it the > > address(es) for however long the server policy dictates. If the > > client doesn't want to use the address after a period of time, it is > > ALWAYS able to RELEASE it whenever it is done. Even if it doesn't > > release it but instead simply lets it expire, what's the harm? There > > should be plenty of addresses available in IPv6. > > The client doesn't just want a short lease. It wants a temporary > address (in addition to a public address). When its current temporary > address expires, it will want to get a new one that is different than > the one it had before. If the client just requested a new address with > shorter lease, it might just get back the one it just had, which > defeats the reason for having temporary addresses. > > > Of course, the requirements document might help answer why Thomas > > feels there is a need to have a mechanism to explicitly request > > these temporary addresses. Perhaps the reason for the 'temporary' > > addresses is that they are supposed to be 'random' instead of based > > on the EUI-64 identifier of the client; but as a previous message > > pointed out nothing has been said as to how a DHCP server will > > assign addresses. > > Not random, but changing over time and not to be reused in a > predictable way. > > Thomas > From owner-dhcp-v6@bucknell.edu Tue Mar 6 19:27:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04923; Tue, 6 Mar 2001 19:27:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f270OQL09278; Tue, 6 Mar 2001 19:24:27 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f270O9L11289 for ; Tue, 6 Mar 2001 19:24:09 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f270O7g19628 for ; Tue, 6 Mar 2001 18:24:07 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Mar 2001 18:24:07 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 18:24:07 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Issue from San Diego IETF - temporary addresses Date: Tue, 6 Mar 2001 18:23:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Thomas, I went and checked 3041 and src addr select 02. More response. > > Narten also raised issue of interaction between DHCP and temporary > > addresses. DHCP server can provide temporary addresses by assigning > > addresses with short lifetimes. However, there will be an API > > through which an application can request a temporary address. How > > can the DHCP server indicate to the client which addresses are to be > > "temporary" and which are "permanent"? Narten thinks IESG will > > bounce anything that doesn't deal with temporary addresses. He will > > develop requirements doc so WG can develop solution. > > Let me try to summarize the issues. The IPv6 architecture now support > the notion of temporary addresses. Temporary addresses are normal > addresses, i.e., they can be used just like other IPv6 > addresses. However, they are designed to be used in cases where the > TCP connection doesn't last forever, i.e., is "short" where short can > mean a few seconds to minutes to hours. It does not mean for weeks or > months. I.e., RFC 3041 suggests that a temporary address be > 'preferred' for one day, and become invalid after a week. So its > really intended for connections that don't last very long. Also, > temporary addresses are intended to be uses by applications/devices > that don't want to expose their (permanent) interface identifier to > remote sites. Also 3041 states the main goal is to remove the use of a constant identifier in IPv6 such as the EUI and was the intention of the IPv6 WG supporting this work. 3041 even says:2.1. Extended Use of the Same Identifier The use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. For example, a network sniffer placed strategically on a link across which all traffic to/from a particular host crosses could keep track of which destinations a node communicated with and at what times. Such information can in some cases be used to infer things, such as what hours an employee was active, when someone is at home, etc. AND The use of a constant identifier within an address is of special concern because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear. Consequently, if a mobile host (e.g., laptop) accessed the network from several different locations, an eavesdropper might be able to track the movement of that mobile host from place to place, even if the upper layer payloads were encrypted [SERIALNUM]. So the core issue is eavesdroppers of constants within an address. Then 3041 states: 2.4. Possible Approaches One way to avoid some of the problems discussed above is to use DHCP for obtaining addresses. With DHCP, the DHCP server could arrange to hand out addresses that change over time. This we can do. But read on. > > There is a need for an API so that applications can indicate if they > want to use a temporary vs. a "public" address, i.e., one that that > doesn't change (or at least, doesn't change until there is a > renumbering event, etc.). That is still a TBD item in IPNG and is not > something this WG needs to worry about too much. This is just a knob an API is not needed. We have these all over IPv6 implementations today. > > For nodes using stateless autoconfiguration, RFC 3041 describes how > temporary addresses are created, when they expire, etc. DHCPv6, > because it can also be used to assign addresses to nodes, needs to > have a story on temporary addresses. That is, a node should be able to > use temporary addresses regardless of whether stateless or stateful > address autoconfiguration is needed. Thus, the DHCPv6 spec needs to > say how temporary addresses are created and/or assigned when DHCPv6 is > used. This is not entirely correct. 3041 does not tell how to create them but only how select that an address has a temporary context based on the lifetimes used for the addresses. By the way what is unclear in 3041 is whether the router or the host alters the lifetimes. That needs to be fixed. My assumption is that its the host and not the router. Also none of this is mandatory for IPv6 or it would never have gotten thru IPng or me. Recall our conversation about this at last call? And as is pointed out in 3041: Use of the extensions defined in this document may complicate debugging and other operational troubleshooting activities. Consequently, it may be site policy that temporary addresses should not be used. Implementations may provide a method for a trusted administrator to override the use of temporary addresses. > > Note that RFC 3041 makes it clear which addresses are "temporary" and > which are not, and the address selection document No they do not. What they do is give an algorithm to set the lifetimes as follows using these constants: TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able to override the default value. TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be able to override the default value. REGEN_ADVANCE -- 5 seconds MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR. It is computed once at system start (rather than each time it is used) and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE). As one who has written the code and shipped in the market stateless addr conf one could set a bit or switch that once the algorithm in 3041 is executed set a bit that this address has undergone the processes to become temporary. But to state that an IPv6 address can be identified for example from tcpdump output by looking at the address as literal, hex, or binary format is not true. An address being temporary is a state and context in an implementation. > draft-ietf-ipngwg-default-addr-select-02.txt makes recommendations on > what to do with temporary addresses. I.e., it is a property of the > address whether it is temporary or not, and that property is exploited > in other parts of the IPv6 architecture. So I believe what DHCPv6 > needs to do is define the mechanics for how temporary addresses are > assigned to nodes. I don't agree with you but will make a proposal for the design meeting the week before the IETF. Also this part of src addr select has no consensus yet. I for one will object to perferring temporary over public as default. But that is an IPng issue. But the main point here is that there is nothing to identify an address as temporary or public anywhere in IPv6 and we should not do that in IPv6. > > > Shouldn't this say "How can the DHCP client indicate to the server > > which addreses are to be "temporary" and which are "permanent"? It > > is after all the client that might have an understanding of how long > > the address is desired. > > I would turn it around. One possible way of providing temporary > address support in DHCP is to allow (require?) that the client request > (via DHCP) that it wants temporary address(es) in addition to regular > addresses. Thats silly Thomas. It is a question of the lease which you deny below. > Note I am not saying the client says how many or anything > other than "it does want temporary addresses". The DHCP server then > *could* return a set of addresses, with the temporary addresses > flagged with a special indication so that the client knows they are > temporary (this is needed for the address selection rules mentioned > earlier) What.. There is nothing in IPv6 to identify an IPv6 address as temporary in stateless and should not be in DHCPv6. Your pushing something into DHCPv6 that does not exist elsewhere and thru sophistry rhetoric using src addr select saying it exists elsewhere and it does not. > > > As the client will send an "Identity Association Option" to request > > address(es), couldn't this simply be communicated via a lease > > request time? Though there probably is no good field to store this > > in. > > I don't think you want to overload lease time for this > purpose. Temporary addresses are semantically different than addresses > with a short lease. NO THEY ARE NOT. Defend this or I suggest this is NOT TRUE. > > > And, then we should perhaps ask WHY DOES THE SERVER CARE? If the > > client wants a short lease, the server simply grants it the > > address(es) for however long the server policy dictates. If the > > client doesn't want to use the address after a period of time, it is > > ALWAYS able to RELEASE it whenever it is done. Even if it doesn't > > release it but instead simply lets it expire, what's the harm? There > > should be plenty of addresses available in IPv6. > > The client doesn't just want a short lease. It wants a temporary > address (in addition to a public address). When its current temporary > address expires, it will want to get a new one that is different than > the one it had before. If the client just requested a new address with > shorter lease, it might just get back the one it just had, which > defeats the reason for having temporary addresses. What Ralph stated is 100% correct based on rfc 3041. Your loosing me totally. > > > Of course, the requirements document might help answer why Thomas > > feels there is a need to have a mechanism to explicitly request > > these temporary addresses. Perhaps the reason for the 'temporary' > > addresses is that they are supposed to be 'random' instead of based > > on the EUI-64 identifier of the client; but as a previous message > > pointed out nothing has been said as to how a DHCP server will > > assign addresses. > > Not random, but changing over time and not to be reused in a > predictable way. The predictability per 3041 is possible to alter. I would argue that we do not even have the same problem unless we use the link-local address from clients as the low order 64bits to hand out an address. And in that case we can use the same algorithm. As in the past your input again is very very very late. We asked you to respond over a month ago. Or do you get special priviledges as an IESG member? /jim From owner-dhcp-v6@bucknell.edu Tue Mar 6 22:19:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08916; Tue, 6 Mar 2001 22:19:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f273GLL00134; Tue, 6 Mar 2001 22:16:21 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f273GJL28811 for ; Tue, 6 Mar 2001 22:16:20 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f273GJg24840 for ; Tue, 6 Mar 2001 21:16:19 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Mar 2001 21:16:19 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 6 Mar 2001 21:16:19 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Cc: Jim.Bound@nokia.com Subject: Temporary Address Solution Date: Tue, 6 Mar 2001 21:16:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Folks, Here is the taxonomy of the solution I can write up fully. Thomas please respond especially (thanks). We should nail this one down on the list and at the design conference before the meeting if possible and present the status. This solution addresses I think Thomas's input and actually gives all the context and end result he requests. The address is identified as temporary and the lease reflects the ruleset in RFC 3041. The other result is that on a client when it gets an address from a server that address can be identified as temporary or public for such things as source address selection etc (not that I personally support such forceful standards in the IETF). Each IA address component in dhcpv6 draft-17 has an 'addr status'. We need to use a bit in the 'addr status' of an address to be defined as follows: TEMP_PUBLIC_STATUS Set (equiv to 1) == Address is Temporary NoTset (equiv to 0) == Address is Public [could make BOOLEAN TYPE too I don't care] Client Requesting a Temporary Address: A client may request a temporary address by setting the TEMP_PUBLIC_STATUS in the addr status field for the address in a Request Message. A client cannot Renew or Rebind Temporary Addresses (they will be rejected by the server). This would defeat the concerns in RFC 3041 otherwise.bv Server Providing Temporary Addresses: Server MUST return to the client a Temporary Address who requested one in a valid Request Message. The Server MAY also give Clients Temporary Addresses who did not ask for them. Server sets the addr status bit TEMP_PUBLIC_STATUS for any addresses which are Temporary. Server Processing of leases for a Temporary Address SHOULD use the ruleset based on current administrative policy for preferred and valid lifetimes for IPv6 addresses as specified in RFC 3031. Servers providing only Prefixes: In a situation where a server only provides a prefix to the clients link-local address then the above can still take place as discussed. Except the responsibility and ownership of randomizing the link-local address IPv6 EUI resides with the Client as stated for Stateless Addrconf in RFC 3041. The dhcp lease provided to the client for Temporary addresses will still be done by the server as stated in Server Providing Temporary Addresses above. regards, /jim From owner-dhcp-v6@bucknell.edu Tue Mar 6 22:35:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10048; Tue, 6 Mar 2001 22:35:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f273XgL09216; Tue, 6 Mar 2001 22:33:42 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f273XJL24955 for ; Tue, 6 Mar 2001 22:33:19 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f273XHi03008 for ; Tue, 6 Mar 2001 21:33:18 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f273XHU04777 for ; Tue, 6 Mar 2001 21:33:17 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Mar 06 21:34:51 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Mar 2001 21:34:51 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F652E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Tue, 6 Mar 2001 21:34:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A6B7.9098C190" 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 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_001_01C0A6B7.9098C190 Content-Type: text/plain; charset="iso-8859-1" Jim: I think I responded to Ralph's posting of the temporary address issue (then Thomas responded to that) with some of the questions/issues regarding the need for special processing of temporary addresses. >From my understanding, I still don't see the need for handling these addresses specially. It really is a client issue (how it wants to treat the address). Recall also that by specifying a different IA, a client can request any number of addresses - since each IA represents a new request. If a client wants a new address, it can simply generate a new IA and request an address for that IA. If the IA space (per client) is large enough, then if you want a new temporary address every week, go for it (by simply requesting a new address via a new IA). If the client wants to limit the time it uses an address, it is always free to release it or let it expire (by not renewing it). Some of your comments below also potentially introduce problems. For example, you state that a temporary address cannot be renewed. However, why can't a client do a renewal (or rebind) on the address? Seems like a client that thinks it might have changed networks might want to renew the address to make sure it is still usable on the network. I can understand it if you want to prevent temporary addresses from having their lease times extended (ie, if the address is valid for a week, the server never would extend it beyond that week but would allow renewals - granting the remaining time on the lease). But renewals until then should be allowed. [Again, I question the need for any special processing in DHCPv6 for this issue.] If we really want this, perhaps another option (no pun intended) is simply to have two options - one that requests 'permanent' addresses and another that requests 'temporary' addresses. Sounds like this might be a good agenda item for the conference call next week? - Bernie Volz -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Tuesday, March 06, 2001 10:16 PM To: DHCPv6 discussion list Cc: Jim.Bound@nokia.com Subject: Temporary Address Solution Folks, Here is the taxonomy of the solution I can write up fully. Thomas please respond especially (thanks). We should nail this one down on the list and at the design conference before the meeting if possible and present the status. This solution addresses I think Thomas's input and actually gives all the context and end result he requests. The address is identified as temporary and the lease reflects the ruleset in RFC 3041. The other result is that on a client when it gets an address from a server that address can be identified as temporary or public for such things as source address selection etc (not that I personally support such forceful standards in the IETF). Each IA address component in dhcpv6 draft-17 has an 'addr status'. We need to use a bit in the 'addr status' of an address to be defined as follows: TEMP_PUBLIC_STATUS Set (equiv to 1) == Address is Temporary NoTset (equiv to 0) == Address is Public [could make BOOLEAN TYPE too I don't care] Client Requesting a Temporary Address: A client may request a temporary address by setting the TEMP_PUBLIC_STATUS in the addr status field for the address in a Request Message. A client cannot Renew or Rebind Temporary Addresses (they will be rejected by the server). This would defeat the concerns in RFC 3041 otherwise.bv Server Providing Temporary Addresses: Server MUST return to the client a Temporary Address who requested one in a valid Request Message. The Server MAY also give Clients Temporary Addresses who did not ask for them. Server sets the addr status bit TEMP_PUBLIC_STATUS for any addresses which are Temporary. Server Processing of leases for a Temporary Address SHOULD use the ruleset based on current administrative policy for preferred and valid lifetimes for IPv6 addresses as specified in RFC 3031. Servers providing only Prefixes: In a situation where a server only provides a prefix to the clients link-local address then the above can still take place as discussed. Except the responsibility and ownership of randomizing the link-local address IPv6 EUI resides with the Client as stated for Stateless Addrconf in RFC 3041. The dhcp lease provided to the client for Temporary addresses will still be done by the server as stated in Server Providing Temporary Addresses above. regards, /jim ------_=_NextPart_001_01C0A6B7.9098C190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Temporary Address Solution

Jim:

I think I responded to Ralph's posting of the = temporary address issue (then Thomas responded to that) with some of = the questions/issues regarding the need for special processing of = temporary addresses.

From my understanding, I still don't see the need for = handling these addresses specially. It really is a client issue (how it = wants to treat the address). Recall also that by specifying a different = IA, a client can request any number of addresses - since each IA = represents a new request. If a client wants a new address, it can = simply generate a new IA and request an address for that IA. If the IA = space (per client) is large enough, then if you want a new temporary = address every week, go for it (by simply requesting a new address via a = new IA). If the client wants to limit the time it uses an address, it = is always free to release it or let it expire (by not renewing = it).

Some of your comments below also potentially = introduce problems. For example, you state that a temporary address = cannot be renewed. However, why can't a client do a renewal (or rebind) = on the address? Seems like a client that thinks it might have changed = networks might want to renew the address to make sure it is still = usable on the network. I can understand it if you want to prevent = temporary addresses from having their lease times extended (ie, if the = address is valid for a week, the server never would extend it beyond = that week but would allow renewals - granting the remaining time on the = lease). But renewals until then should be allowed. [Again, I question = the need for any special processing in DHCPv6 for this = issue.]

If we really want this, perhaps another option (no = pun intended) is simply to have two options - one that requests = 'permanent' addresses and another that requests 'temporary' = addresses.

Sounds like this might be a good agenda item for the = conference call next week?

- Bernie Volz

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Tuesday, March 06, 2001 10:16 PM
To: DHCPv6 discussion list
Cc: Jim.Bound@nokia.com
Subject: Temporary Address Solution


Folks,

Here is the taxonomy of the solution I can write up = fully.  Thomas please
respond especially (thanks).

We should nail this one down on the list and at the = design conference before
the meeting if possible and present the = status.

This solution addresses I think Thomas's input and = actually gives all the
context and end result he requests.
The address is identified as temporary and the lease = reflects the ruleset in
RFC 3041.  The other result is that on a client = when it gets an address from
a server that address can be identified as temporary = or public for such
things as source address selection etc (not that I = personally support such
forceful standards in the IETF). 

Each IA address component in dhcpv6 draft-17 has an = 'addr status'.

We need to use a bit in the 'addr status' of an = address to be defined as
follows:

TEMP_PUBLIC_STATUS
 Set (equiv to 1) =3D=3D Address is = Temporary
 NoTset (equiv to 0) =3D=3D Address is = Public
 [could make BOOLEAN TYPE too I don't = care]

Client Requesting a Temporary Address:
A client may request a temporary address by setting = the TEMP_PUBLIC_STATUS
in the addr status field for the address in a = Request Message.

A client cannot Renew or Rebind Temporary Addresses = (they will be rejected
by the server).  This would defeat the concerns = in RFC 3041 otherwise.bv

Server Providing Temporary Addresses:
Server MUST return to the client a Temporary Address = who requested one in a
valid Request Message.
The Server MAY also give Clients Temporary Addresses = who did not ask for
them.
Server sets the addr status bit TEMP_PUBLIC_STATUS = for any addresses which
are Temporary.

Server Processing of leases for a Temporary Address = SHOULD use the ruleset
based on current administrative policy for preferred = and valid lifetimes for
IPv6 addresses as specified in RFC 3031.

Servers providing only Prefixes:
In a situation where a server only provides a prefix = to the clients
link-local address then the above can still take = place as discussed.  Except
the responsibility and ownership of randomizing the = link-local address IPv6
EUI resides with the Client as stated for Stateless = Addrconf in RFC 3041.
The dhcp lease provided to the client for Temporary = addresses will still be
done by the server as stated in Server Providing = Temporary Addresses above.

regards,
/jim

------_=_NextPart_001_01C0A6B7.9098C190-- From owner-dhcp-v6@bucknell.edu Wed Mar 7 06:38:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29657; Wed, 7 Mar 2001 06:38:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f27BZFL08400; Wed, 7 Mar 2001 06:35:15 -0500 (EST) 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 f27BZ7L20854 for ; Wed, 7 Mar 2001 06:35:07 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA10345; Wed, 7 Mar 2001 06:34:50 -0500 (EST) Message-Id: <4.3.2.7.2.20010307062041.01931820@mail.bucknell.edu> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Mar 2001 06:34:38 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: A proposal for DHCPv6 reconfiguration Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC691F64F7@eambunt705.ena-east .ericsson.se> 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 09:43 AM 3/1/2001 -0600, Bernie Volz (EUD) wrote: >See below (prefixed by BV>). > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, March 01, 2001 10:21 AM >To: DHCPv6 discussion list >Subject: RE: A proposal for DHCPv6 reconfiguration > >At 08:46 AM 3/1/2001 -0600, you wrote: > >I also agree with Erik that the delay parameter should be required, not > >optional. > >Suppose we define a mandatory default that can be optionally modified? > >BV> That would also work. But, it means another client side configuration >parameter >BV> and specifying a default value. I'd prefer to have to set it in ONE place >BV> and so I'd prefer to make it mandatory on the server. Of course, it >would be >BV> sent as an option, so the question is what is a client to do if there >is no >BV> option - I'd say IGNORE the Reconfigure-Init as it is a bogus request. OK. This issue should be on our design team teleconference agenda next week. > > >As an aside, the behavior of a client that receives a > > >Reconfigure-init while expecting an Advertise or Reply > > >is not currently defined and is TBD. > > > >Regarding this issue, are you referring to whether the client sends a > >Reply to the Reconfigure-Init or whether the client does the > >reconfiguration? I do think it should send a Reply (that way, if the > >server is keeping track of the clients, it can know that this client > >responded). Whether the client does the reconfigure depends on whether it > >has already obtained any configuration information or not. If it is > >waiting for an Advertise (and has no configuration data), it should just > >continue. If waiting for a Reply, I would think it best to continue > >waiting for that Reply and reconfiguring afterwards? > >In the current spec, clients respond to a Reconfigure-init with a Request >message (this is the "reconfigure as trigger" model). Only servers send >Reply messages in the current spec. > >BV> I was using terminology from your original message. Such as: >BV> "If the server does not receive a Reply to the Reconfigure-init >BV> with a matching transaction ID ...". So, hopefully that text did not >BV> come from the draft. Oops. Thanks for catching that goof on my part. The draft reads (correctly): If the server does not receive a Request message from the client in RECREP_MSG_TIMEOUT milliseconds, the server retransmits the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT value and waits again. >We could specify that the client always initiates a Request-Reply >transaction when it receives a Reconfigure-init, regardless of the client's >current state. Here are the two cases: > >* Sent Solicit, waiting for Advertise - client is > looking for a server. It can use the server in > the Reconfigure-init and send a Request to that > server >BV> In this case, it seems better to ignore the Reconfigure-Init unless the >BV> client already has addresses and then it should do the Request to the >BV> server. Hm. I don't see why the client's behavior would change if it has addresses. Sounds like another issues for design team teleconference. >* Sent Request/Renew/Rebind, waiting for Reply - info > in Reply after Reconfigure-init is likely to be more > current than in Reply to previous message, so send > new Request and ignore Reply to earlier message >BV> That sounds OK. > >- Ralph > >BV> Another issue, if the Reconfigure-Init causes a Request, the >Transaction-ID >BV> for the Request can't really be copied from the Reconfigure-Init as that >BV> would mix two transaction-Id number spaces (one from the client and >one from >BV> the server). Did we solve this by having a "Reconfigure-XID" option >that is >BV> used by the client to specify that the Request is in response to a >BV> Reconfigure-Init with the transaction ID in the message? Or am I >confused. No - there is no mechanism to disambiguate client-initiated and server-initiated Request messages. Thus, a transaction-ID from a server could collide with a client-selected transaction-ID. I like your Reconfigure-XID option. - Ralph From owner-dhcp-v6@bucknell.edu Wed Mar 7 12:03:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11571; Wed, 7 Mar 2001 12:03:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f27GxwL19564; Wed, 7 Mar 2001 11:59:58 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f27GxnL02552 for ; Wed, 7 Mar 2001 11:59:49 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f27H1Zw15493 for ; Wed, 7 Mar 2001 11:01:35 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Mar 2001 10:59:47 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 7 Mar 2001 10:59:47 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Wed, 7 Mar 2001 10:59:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A728.02EE0E60" 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 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_001_01C0A728.02EE0E60 Content-Type: text/plain; charset="iso-8859-1" Hi Bernie, By the way we (authors) really appreciate you rolling up your sleeves and working on the spec its appreciated. . >From my understanding, I still don't see the need for handling these addresses specially. It really is a client issue (how it wants to treat the address). Recall also that by specifying a different IA, a client can request any number of addresses - since each IA represents a new request. If a client wants a new address, it can simply generate a new IA and request an address for that IA. If the IA space (per client) is large enough, then if you want a new temporary address every week, go for it (by simply requesting a new address via a new IA). If the client wants to limit the time it uses an address, it is always free to release it or let it expire (by not renewing it). Agree with you on this point. Some of your comments below also potentially introduce problems. For example, you state that a temporary address cannot be renewed. However, why can't a client do a renewal (or rebind) on the address? Seems like a client that thinks it might have changed networks might want to renew the address to make sure it is still usable on the network. I can understand it if you want to prevent temporary addresses from having their lease times extended (ie, if the address is valid for a week, the server never would extend it beyond that week but would allow renewals - granting the remaining time on the lease). But renewals until then should be allowed. [Again, I question the need for any special processing in DHCPv6 for this issue.] First I question the need to in general. But Thomas is on the IESG and raised the issue quite elegantly. We need to address it. The reason we cannot do Renew or Rebind is pretty clear if you read rfc 3041. The object is to make sure temporary address tokens or parts cannot be learned on the network from repeated use. If we let a client Renew and Rebind a Temporary address that point is defeated in rfc 3041 There is no reason to Renew if the lease has not expired and other servers should not be giving out Temporary addresses in our Rebind state. The Confirm is fine fyi. If we really want this, perhaps another option (no pun intended) is simply to have two options - one that requests 'permanent' addresses and another that requests 'temporary' addresses. I went down that path while eating dinner last night after seeing Thomas's mail. But I think setting a bit in the addr status does the same thing. I don't care that would be fine with me too. Sounds like this might be a good agenda item for the conference call next week? Yes I agree. I just don't want this or any other issue hold us up wrapping up this spec to get to last call to the IESG so we can get folks writing code and for this spec they will not do that until we hit PS because we have been working on this for some time. I think fyi this latest specs are really really good so just trying to keep the ball rolling. thanks /jim ------_=_NextPart_001_01C0A728.02EE0E60 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
Hi Bernie,
 
By the way we (authors) really appreciate you rolling up your sleeves and working on the spec its appreciated.

.

From my understanding, I still don't see the need for handling these addresses specially. It really is a client issue (how it wants to treat the address). Recall also that by specifying a different IA, a client can request any number of addresses - since each IA represents a new request. If a client wants a new address, it can simply generate a new IA and request an address for that IA. If the IA space (per client) is large enough, then if you want a new temporary address every week, go for it (by simply requesting a new address via a new IA). If the client wants to limit the time it uses an address, it is always free to release it or let it expire (by not renewing it). 

Agree with you on this point. 

Some of your comments below also potentially introduce problems. For example, you state that a temporary address cannot be renewed. However, why can't a client do a renewal (or rebind) on the address? Seems like a client that thinks it might have changed networks might want to renew the address to make sure it is still usable on the network. I can understand it if you want to prevent temporary addresses from having their lease times extended (ie, if the address is valid for a week, the server never would extend it beyond that week but would allow renewals - granting the remaining time on the lease). But renewals until then should be allowed. [Again, I question the need for any special processing in DHCPv6 for this issue.] 

First I question the need to in general. But Thomas is on the IESG and raised the issue quite elegantly.  We need to address it.  The reason we cannot do Renew or Rebind is pretty clear if you read rfc 3041.  The object is to make sure temporary address tokens or parts cannot be learned on the network from repeated use.  If we let a client Renew and Rebind a Temporary address that point is defeated in rfc 3041   There is no reason to Renew if the lease has not expired and other servers should not be giving out Temporary addresses in our Rebind state.  The Confirm is fine fyi.

If we really want this, perhaps another option (no pun intended) is simply to have two options - one that requests 'permanent' addresses and another that requests 'temporary' addresses. 

I went down that path while eating dinner last night after seeing Thomas's mail.  But I think setting a bit in the addr status does the same thing.  I don't care that would be fine with me too. 

Sounds like this might be a good agenda item for the conference call next week?  

Yes I agree.  I just don't want this or any other issue hold us up wrapping up this spec to get to last call to the IESG so we can get folks writing code and for this spec they will not do that until we hit PS because we have been working on this for some time.  I think fyi this latest specs are really really good so just trying to keep the ball rolling.

thanks

/jim

 

------_=_NextPart_001_01C0A728.02EE0E60-- From owner-dhcp-v6@bucknell.edu Wed Mar 7 13:28:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15717; Wed, 7 Mar 2001 13:28:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f27IOmL15696; Wed, 7 Mar 2001 13:24:48 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f27IOPL16789 for ; Wed, 7 Mar 2001 13:24:39 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f27IOMi22896 for ; Wed, 7 Mar 2001 12:24:22 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f27IOLU22972 for ; Wed, 7 Mar 2001 12:24:21 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Mar 07 12:25:57 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Mar 2001 12:25:57 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F6539@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Wed, 7 Mar 2001 12:25:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A734.0B1000B0" 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 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_001_01C0A734.0B1000B0 Content-Type: text/plain; charset="iso-8859-1" Jim: I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Wednesday, March 07, 2001 12:00 PM To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Hi Bernie, By the way we (authors) really appreciate you rolling up your sleeves and working on the spec its appreciated. . >From my understanding, I still don't see the need for handling these addresses specially. It really is a client issue (how it wants to treat the address). Recall also that by specifying a different IA, a client can request any number of addresses - since each IA represents a new request. If a client wants a new address, it can simply generate a new IA and request an address for that IA. If the IA space (per client) is large enough, then if you want a new temporary address every week, go for it (by simply requesting a new address via a new IA). If the client wants to limit the time it uses an address, it is always free to release it or let it expire (by not renewing it). Agree with you on this point. Some of your comments below also potentially introduce problems. For example, you state that a temporary address cannot be renewed. However, why can't a client do a renewal (or rebind) on the address? Seems like a client that thinks it might have changed networks might want to renew the address to make sure it is still usable on the network. I can understand it if you want to prevent temporary addresses from having their lease times extended (ie, if the address is valid for a week, the server never would extend it beyond that week but would allow renewals - granting the remaining time on the lease). But renewals until then should be allowed. [Again, I question the need for any special processing in DHCPv6 for this issue.] First I question the need to in general. But Thomas is on the IESG and raised the issue quite elegantly. We need to address it. The reason we cannot do Renew or Rebind is pretty clear if you read rfc 3041. The object is to make sure temporary address tokens or parts cannot be learned on the network from repeated use. If we let a client Renew and Rebind a Temporary address that point is defeated in rfc 3041 There is no reason to Renew if the lease has not expired and other servers should not be giving out Temporary addresses in our Rebind state. The Confirm is fine fyi. If we really want this, perhaps another option (no pun intended) is simply to have two options - one that requests 'permanent' addresses and another that requests 'temporary' addresses. I went down that path while eating dinner last night after seeing Thomas's mail. But I think setting a bit in the addr status does the same thing. I don't care that would be fine with me too. Sounds like this might be a good agenda item for the conference call next week? Yes I agree. I just don't want this or any other issue hold us up wrapping up this spec to get to last call to the IESG so we can get folks writing code and for this spec they will not do that until we hit PS because we have been working on this for some time. I think fyi this latest specs are really really good so just trying to keep the ball rolling. thanks /jim ------_=_NextPart_001_01C0A734.0B1000B0 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
Jim:
 
I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully.
 
If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address.
 
Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for.
 
A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time).
 
We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid.
 
- Bernie
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Wednesday, March 07, 2001 12:00 PM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Hi Bernie,
 
By the way we (authors) really appreciate you rolling up your sleeves and working on the spec its appreciated.

.

From my understanding, I still don't see the need for handling these addresses specially. It really is a client issue (how it wants to treat the address). Recall also that by specifying a different IA, a client can request any number of addresses - since each IA represents a new request. If a client wants a new address, it can simply generate a new IA and request an address for that IA. If the IA space (per client) is large enough, then if you want a new temporary address every week, go for it (by simply requesting a new address via a new IA). If the client wants to limit the time it uses an address, it is always free to release it or let it expire (by not renewing it). 

Agree with you on this point. 

Some of your comments below also potentially introduce problems. For example, you state that a temporary address cannot be renewed. However, why can't a client do a renewal (or rebind) on the address? Seems like a client that thinks it might have changed networks might want to renew the address to make sure it is still usable on the network. I can understand it if you want to prevent temporary addresses from having their lease times extended (ie, if the address is valid for a week, the server never would extend it beyond that week but would allow renewals - granting the remaining time on the lease). But renewals until then should be allowed. [Again, I question the need for any special processing in DHCPv6 for this issue.] 

First I question the need to in general. But Thomas is on the IESG and raised the issue quite elegantly.  We need to address it.  The reason we cannot do Renew or Rebind is pretty clear if you read rfc 3041.  The object is to make sure temporary address tokens or parts cannot be learned on the network from repeated use.  If we let a client Renew and Rebind a Temporary address that point is defeated in rfc 3041   There is no reason to Renew if the lease has not expired and other servers should not be giving out Temporary addresses in our Rebind state.  The Confirm is fine fyi.

If we really want this, perhaps another option (no pun intended) is simply to have two options - one that requests 'permanent' addresses and another that requests 'temporary' addresses. 

I went down that path while eating dinner last night after seeing Thomas's mail.  But I think setting a bit in the addr status does the same thing.  I don't care that would be fine with me too. 

Sounds like this might be a good agenda item for the conference call next week?  

Yes I agree.  I just don't want this or any other issue hold us up wrapping up this spec to get to last call to the IESG so we can get folks writing code and for this spec they will not do that until we hit PS because we have been working on this for some time.  I think fyi this latest specs are really really good so just trying to keep the ball rolling.

thanks

/jim

 

------_=_NextPart_001_01C0A734.0B1000B0-- From owner-dhcp-v4@bucknell.edu Thu Mar 8 07:03:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22861 for ; Thu, 8 Mar 2001 07:03:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28BtNL08639; Thu, 8 Mar 2001 06:55:23 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f28Bt8L08591 for ; Thu, 8 Mar 2001 06:55:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22025; Thu, 8 Mar 2001 06:55:03 -0500 (EST) Message-Id: <200103081155.GAA22025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-ddns-resolution-01.txt Date: Thu, 08 Mar 2001 06:55:03 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp Filename : draft-ietf-dhc-ddns-resolution-01.txt Pages : 13 Date : 07-Mar-01 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS(RFC1034[1], RFC1035[2]), and specifically updating the name to address and address to name mappings maintained in the DNS. The 'Client FQDN Option'[14] specifies the client FQDN option, through which DHCP clients and servers can exchange information about client FQDNs. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-ddns-resolution-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307141807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307141807.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Mar 8 07:04:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22878 for ; Thu, 8 Mar 2001 07:04:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28C1CL27624; Thu, 8 Mar 2001 07:01:12 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f28Bt9L14710 for ; Thu, 8 Mar 2001 06:55:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22042; Thu, 8 Mar 2001 06:55:07 -0500 (EST) Message-Id: <200103081155.GAA22042@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-fqdn-option-01.txt Date: Thu, 08 Mar 2001 06:55:07 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The DHCP Client FQDN Option Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-fqdn-option-01.txt Pages : 14 Date : 07-Mar-01 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, or 'FQDN'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-fqdn-option-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-fqdn-option-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307141816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307141816.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Thu Mar 8 10:45:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00180; Thu, 8 Mar 2001 10:45:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28FeXL15338; Thu, 8 Mar 2001 10:40:33 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f28FeTL31033 for ; Thu, 8 Mar 2001 10:40:29 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f28Fe6g04841 for ; Thu, 8 Mar 2001 09:40:16 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 8 Mar 2001 09:40:04 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 8 Mar 2001 09:40:04 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Thu, 8 Mar 2001 09:40:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A7E6.09F60A50" 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 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_001_01C0A7E6.09F60A50 Content-Type: text/plain; charset="iso-8859-1" Bernie I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. OK If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe. We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal. We don't have to worry about it again. You have not told me anything that is wrong with what I proposed and it solves the problem completely. Open to hearing why you don't think it solves the problem and what I may be missing as always. Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. No. Temporary address has now a context per Thomas' mail. We need to now differentiate temporary from public that is the issue. If we don't do that then we are not solving the needs of that requirement . A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). That does not solve the problem as Thomas pointed out in his response to Ralph. We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid. Your first sentence is just the confirm request. We should not allow renew or rebind. thanks /jim ------_=_NextPart_001_01C0A7E6.09F60A50 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
Bernie
 
I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. 
 
OK 
 
If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. 
 
I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe.  We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal.  We don't have to worry about it again.
 
You have not told me anything that is wrong with what I proposed and it solves the problem completely.  Open to hearing why you don't think it solves the problem and what I may be missing as always.
 
 
Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. 
 
No. Temporary address has now a context per Thomas' mail.  We need to now differentiate temporary from public that is the issue.  If we don't do that then we are not solving the needs of that requirement .
 
A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). 
 
That does not solve the problem as Thomas pointed out in his response to Ralph.   
 
We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid.  
 
Your first sentence is just the confirm request.  We should not allow renew or rebind.
 
thanks
/jim 
 
------_=_NextPart_001_01C0A7E6.09F60A50-- From owner-dhcp-v6@bucknell.edu Thu Mar 8 11:25:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02210; Thu, 8 Mar 2001 11:25:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28GKtL05262; Thu, 8 Mar 2001 11:20:55 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f28GKmL08221 for ; Thu, 8 Mar 2001 11:20:48 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f28GKng11109 for ; Thu, 8 Mar 2001 10:20:49 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 8 Mar 2001 10:20:48 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 8 Mar 2001 10:20:48 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Thu, 8 Mar 2001 10:20:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A7EB.BA1EFCC0" 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 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_001_01C0A7EB.BA1EFCC0 Content-Type: text/plain; charset="iso-8859-1" folks it appears ms mail is hosing me here is my reply to bernie again -----Original Message----- From: ext Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Thursday,March 08,2001 10:40 AM To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Bernie I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. [JPB] ** OK If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. [JPB] *** I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe. We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal. We don't have to worry about it again. [JPB] ** You have not told me anything that is wrong with what I proposed and it solves the problem completely. Open to hearing why you don't think it solves the problem and what I may be missing as always. Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. [JPB] *** No. Temporary address has now a context per Thomas' mail. We need to now differentiate temporary from public that is the issue. If we don't do that then we are not solving the needs of that requirement . A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). T[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph. We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid. [JPB] ** Your first sentence is just the confirm request. We should not allow renew or rebind. thanks /jim ------_=_NextPart_001_01C0A7EB.BA1EFCC0 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
folks it appears ms mail is hosing me here is my reply to bernie again
-----Original Message-----
From: ext Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Thursday,March 08,2001 10:40 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Bernie
 
I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. 
 
[JPB] ** OK 
 
If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. 
 
[JPB] *** I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe.  We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal.  We don't have to worry about it again.
 
[JPB] ** You have not told me anything that is wrong with what I proposed and it solves the problem completely.  Open to hearing why you don't think it solves the problem and what I may be missing as always.
 
 
Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. 
 
[JPB] *** No. Temporary address has now a context per Thomas' mail.  We need to now differentiate temporary from public that is the issue.  If we don't do that then we are not solving the needs of that requirement .
 
 A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). 
 
T[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
 
We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid.  
 
[JPB] ** Your first sentence is just the confirm request.  We should not allow renew or rebind.
 
thanks
/jim 
 
------_=_NextPart_001_01C0A7EB.BA1EFCC0-- From owner-dhcp-v6@bucknell.edu Thu Mar 8 16:02:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13229; Thu, 8 Mar 2001 16:02:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28KwvL26020; Thu, 8 Mar 2001 15:58:57 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f28KwsL20503 for ; Thu, 8 Mar 2001 15:58:54 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f28Kwqi27607 for ; Thu, 8 Mar 2001 14:58:52 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f28Kwq504306 for ; Thu, 8 Mar 2001 14:58:52 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Mar 08 15:00:28 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 15:00:27 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F655C@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Thu, 8 Mar 2001 15:00:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A812.CA51F3A0" 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 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_001_01C0A812.CA51F3A0 Content-Type: text/plain; charset="iso-8859-1" Jim: I do think we are basically in agreement. Though I don't understand your response to my comment: [BV] A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). [JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph. All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server: - Don't assign the same address(es) that might have been previously assigned for that IA. - Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.] - Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime). Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes. >From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO. One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache. - Bernie PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances. -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Thursday, March 08, 2001 11:21 AM To: DHCPv6 discussion list Subject: RE: Temporary Address Solution folks it appears ms mail is hosing me here is my reply to bernie again -----Original Message----- From: ext Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Thursday,March 08,2001 10:40 AM To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Bernie I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. [JPB] ** OK If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. [JPB] *** I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe. We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal. We don't have to worry about it again. [JPB] ** You have not told me anything that is wrong with what I proposed and it solves the problem completely. Open to hearing why you don't think it solves the problem and what I may be missing as always. Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. [JPB] *** No. Temporary address has now a context per Thomas' mail. We need to now differentiate temporary from public that is the issue. If we don't do that then we are not solving the needs of that requirement . A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). T[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph. We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid. [JPB] ** Your first sentence is just the confirm request. We should not allow renew or rebind. thanks /jim ------_=_NextPart_001_01C0A812.CA51F3A0 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
Jim:
 
I do think we are basically in agreement.
 
Though I don't understand your response to my comment:
 
[BV] A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). 
 
[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
 
All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server:
- Don't assign the same address(es) that might have been previously assigned for that IA.
- Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.]
- Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime).
 
Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes.
 
From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO.
 
One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache.
 
- Bernie
 
PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances.
 
 -----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Thursday, March 08, 2001 11:21 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

folks it appears ms mail is hosing me here is my reply to bernie again
-----Original Message-----
From: ext Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Thursday,March 08,2001 10:40 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Bernie
 
I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. 
 
[JPB] ** OK 
 
If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. 
 
[JPB] *** I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe.  We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal.  We don't have to worry about it again.
 
[JPB] ** You have not told me anything that is wrong with what I proposed and it solves the problem completely.  Open to hearing why you don't think it solves the problem and what I may be missing as always.
 
 
Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. 
 
[JPB] *** No. Temporary address has now a context per Thomas' mail.  We need to now differentiate temporary from public that is the issue.  If we don't do that then we are not solving the needs of that requirement .
 
 A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). 
 
T[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
 
We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid.  
 
[JPB] ** Your first sentence is just the confirm request.  We should not allow renew or rebind.
 
thanks
/jim 
 
------_=_NextPart_001_01C0A812.CA51F3A0-- From owner-dhcp-v4@bucknell.edu Thu Mar 8 16:17:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13672 for ; Thu, 8 Mar 2001 16:17:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28LCVL00591; Thu, 8 Mar 2001 16:12:31 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f28LCIL30532 for ; Thu, 8 Mar 2001 16:12:19 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f28KIbi23950 for ; Thu, 8 Mar 2001 14:18:41 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f28KIa516136 for ; Thu, 8 Mar 2001 14:18:36 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 08 14:20:12 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 14:20:13 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F655A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: Latest DNS/DHCP Interaction Drafts Date: Thu, 8 Mar 2001 14:20:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A80D.2DF0F060" Reply-To: Bernie.Volz@am1.ericsson.se 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_001_01C0A80D.2DF0F060 Content-Type: text/plain; charset="iso-8859-1" Mark, et al: Is it safe to conclude that draft-ietf-dhc-ddns-resolution-01.txt and draft-ietf-dnsext-dhcid-rr-02.txt have essentially editorial changes and that draft-ietf-dhc-fqdn-option-01.txt has editorial changes AND the addition of the "N" bit for the client to request (and server to honor) the DDNS updates. Thanks in advance. - Bernie Volz ------_=_NextPart_001_01C0A80D.2DF0F060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Latest DNS/DHCP Interaction Drafts

Mark, et al:

Is it safe to conclude that = draft-ietf-dhc-ddns-resolution-01.txt and = draft-ietf-dnsext-dhcid-rr-02.txt have essentially editorial changes = and that draft-ietf-dhc-fqdn-option-01.txt has editorial changes AND = the addition of the "N" bit for the client to request (and = server to honor) the DDNS updates.

Thanks in advance.

- Bernie Volz

------_=_NextPart_001_01C0A80D.2DF0F060-- From owner-dhcp-v4@bucknell.edu Thu Mar 8 16:41:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14268 for ; Thu, 8 Mar 2001 16:41:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f28LXsL02330; Thu, 8 Mar 2001 16:33:54 -0500 (EST) 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 f28LXmL19611 for ; Thu, 8 Mar 2001 16:33:48 -0500 (EST) Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA18968; Thu, 8 Mar 2001 16:33:24 -0500 (EST) Message-Id: <4.3.2.7.2.20010308161757.00b54550@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Mar 2001 16:27:57 -0500 To: DHCPv4 discussion list From: Mark Stapp Subject: Re: Latest DNS/DHCP Interaction Drafts Cc: DHCPv4 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC691F655A@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: mjs@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, Yes. I tried to come up with "N"-bit language for the fqdn option that matched my recollection of the discussion the working-group had when it was proposed during a (somewhat) recent ietf. I'd received a couple of questions about the fqdn field in the option, and I tried to tighten up the language there too. Ted Lemon sent me some suggestions about the last dhcid rr draft, and I tried to incorporate them for this round. I still intend to add a picture or two to the resolution draft, as I think that a diagram would help folks unfamiliar with the discussion understand the kinds of problems that can occur. I haven't received questions or suggestions about that draft in some months, so I'd like to infer that it's getting close. -- Mark At 02:20 PM 3/8/01 -0600, Bernie Volz (EUD) wrote: >Mark, et al: > >Is it safe to conclude that draft-ietf-dhc-ddns-resolution-01.txt and >draft-ietf-dnsext-dhcid-rr-02.txt have essentially editorial changes and >that draft-ietf-dhc-fqdn-option-01.txt has editorial changes AND the >addition of the "N" bit for the client to request (and server to honor) >the DDNS updates. > >Thanks in advance. > >- Bernie Volz From owner-dhcp-v6@bucknell.edu Fri Mar 9 09:15:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14414; Fri, 9 Mar 2001 09:15:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29EBEL03132; Fri, 9 Mar 2001 09:11:15 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29EB3L29365 for ; Fri, 9 Mar 2001 09:11:03 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f29E8a004025 for ; Fri, 9 Mar 2001 09:08:36 -0500 Message-Id: <200103091408.f29E8a004025@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: Issue from San Diego IETF - temporary addresses In-Reply-To: Message from Jim.Bound@nokia.com of "Tue, 06 Mar 2001 17:24:04 CST." Date: Fri, 09 Mar 2001 09:08:36 -0500 From: Thomas Narten 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 Catching up on a number of postings.. Jim.Bound@nokia.com writes: > There is no way to differentiate a temp addr from other addr > semantically. Please give us an example I don't see this in src > addr select at all. In fact there are no bits in IPv6 addr arch > anywhere to support this. I agree that there is no way to distinguish temporary addresses from other ones by looking at them (i.e., syntactically). But there are times when an implementation needs to know whether an address is temporary or not. Hence, if DHCP is to be used to send temporary addresses from the server to the client, there will need to be a way to flag this. E.g., a bit in the extention. Note: the addr-select document in the ID directory is old. Per a note to the IPNg list: "Richard Draves" writes: > I submitted these twelve hours before the deadline, but somehow they > didn't get there in time: > ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngwg-default-addr-select-03.txt > ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-selection-01.txt Temporary addresses are described in the default-addr-select document. > Putting on my IPv6 hat I got to say that your statement that > temporary addresses are part of the IPv6 address architecture is NOT > TRUE. Its an appeasement for paranoids. I suspect we're having a disagreement over terminology more than substance. Temporary addresses exist, they are part of the overall IPv6 picture. Not everyone needs to implement them. But because they are part of the overall picture, and they fit in with the existing IPv6 architecture, I say they are part of the architecture. > > > > There is a need for an API so that applications can indicate if they > > want to use a temporary vs. a "public" address, i.e., one that that > > doesn't change (or at least, doesn't change until there is a > > renumbering event, etc.). That is still a TBD item in IPNG and is not > > something this WG needs to worry about too much. > This is just a knob an API is not needed. We have these all over IPv6 > implementations today. We're in agreement, just differing on terminology. I'm assuming "new API" means extensions to the existing ones (i.e., the basic API). Note also that if an application can indicate (through the API) that it does (or does not) want temporary addresses used, that is another reason why such addresses must be distinguishable within an implementation. I.e, source address selection indicates how to choose temporary vs. public addresses when the application doesn't care, the API is needed so that applications can override the defaults. > > > > For nodes using stateless autoconfiguration, RFC 3041 describes how > > temporary addresses are created, when they expire, etc. DHCPv6, > > because it can also be used to assign addresses to nodes, needs to > > have a story on temporary addresses. That is, a node should be able to > > use temporary addresses regardless of whether stateless or stateful > > address autoconfiguration is needed. Thus, the DHCPv6 spec needs to > > say how temporary addresses are created and/or assigned when DHCPv6 is > > used. > This is not entirely correct. 3041 does not tell how to create them but > only how select that an address has a temporary context based on the > lifetimes used for the addresses. By the way what is unclear in 3041 is > whether the router or the host alters the lifetimes. That needs to be > fixed. My assumption is that its the host and not the router. The host does the lifetimes. > Also none of this is mandatory for IPv6 or it would never have gotten thru > IPng or me. Recall our conversation about this at last call? And as is > pointed out in 3041: > Use of the extensions defined in this document may complicate > debugging and other operational troubleshooting activities. > Consequently, it may be site policy that temporary addresses should > not be used. Implementations may provide a method for a trusted > administrator to override the use of temporary addresses. > > > > Note that RFC 3041 makes it clear which addresses are "temporary" and > > which are not, and the address selection document > No they do not. What they do is give an algorithm to set the lifetimes as > follows using these constants: > TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able > to override the default value. > TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be > able to override the default value. > REGEN_ADVANCE -- 5 seconds > MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. > DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR. > It is computed once at system start (rather than each time > it is used) and must never be greater than > (TEMP_VALID_LIFETIME - REGEN_ADVANCE). > As one who has written the code and shipped in the market stateless addr > conf one could set a bit or switch that once the algorithm in 3041 is > executed set a bit that this address has undergone the processes to become > temporary. > But to state that an IPv6 address can be identified for example from tcpdump > output by looking at the address as literal, hex, or binary format is not > true. We are miscommunicating, as I have never stated that one can identify temporary addresses via tcpdump. > An address being temporary is a state and context in an > implementation. I agree. But *if* DHCP supports temporary addresses by having the server send them to the client, there would seem to need to be a way for those addresses to be flagged as temporary. Stateless addrconf doesn't have this issue because its all internal to the implementation (e.g., not on the wire). Also, I'm not saying that DHCP has to support temporary addresses this way. Another approach would be for the the DHCP server to send the client the routing prefix and then have the host do everything else, ala 3041. I wonder though if this is the "right" model in an enviroment where DHCP is being used. I.e., presumably a site using DHCP wants to know *ALL* the addresses that are in use and by whom, and having the client generate them would not support this. This is something the WG needs to work through. Note: I'm not responding to some of your other points because I think they all result from a more basic disagreement that is addresses earlier in this note. Those may need to be revisited if this note isn't clarifying things. Thomas From owner-dhcp-v6@bucknell.edu Fri Mar 9 09:16:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14449; Fri, 9 Mar 2001 09:16:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29ECtL03888; Fri, 9 Mar 2001 09:12:55 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29EBwL29923 for ; Fri, 9 Mar 2001 09:11:58 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f29E9VV04034 for ; Fri, 9 Mar 2001 09:09:31 -0500 Message-Id: <200103091409.f29E9VV04034@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Server address assignment policies Re: [was: Temporary Address Solution] In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 07 Mar 2001 12:25:53 CST." <66F66129A77AD411B76200508B65AC691F6539@eambunt705.ena-east.ericsson.se> Date: Fri, 09 Mar 2001 09:09:31 -0500 From: Thomas Narten 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 Volz (EUD)" writes: > If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then > one question that I've raised several times comes up again ... what > are the recommendations for HOW a DHCPv6 server is supposed to > 'generate' addresses? If we ignore the multiple addresses per prefix > for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 > addresses based on the client's [IEEE] hardware identifier? If we > say no it should not, than at worst case you'd have the same lower > address bits every time you connected to a particular network > (however you'd have different addresses on different > networks). Hence, you'd only be leaking as much information as IPv4 > does. Your at home lower address bits would not be the same as your > at work lower address bits since different DHCP servers would be > used to generate the address. > Of course, we might want to improve things even more with IPv6 and > not reassign the same address even when you reconnect to the > network. This would be what the temporary address request could be > used for. My take would be that the document should explain that how it assigns addresses is an important topic with interesting implications, and give suggestions on what a server should do. It might even make sense to recommend that server support a number of ways of assiging addresses (e.g., just use EUI-64 for interface ID, use random numbers, number sequentially starting at 1, etc.), with knobs in a config file for selecting which policy one wants. Thomas From owner-dhcp-v6@bucknell.edu Fri Mar 9 09:16:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14478; Fri, 9 Mar 2001 09:16:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29ECvL03186; Fri, 9 Mar 2001 09:12:57 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29ECCL27938 for ; Fri, 9 Mar 2001 09:12:12 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f29E9jR04042; Fri, 9 Mar 2001 09:09:45 -0500 Message-Id: <200103091409.f29E9jR04042@hygro.adsl.duke.edu> To: DHCPv6 discussion list cc: Jim.Bound@nokia.com Subject: Re: Temporary Address Solution In-Reply-To: Message from Jim.Bound@nokia.com of "Tue, 06 Mar 2001 21:16:17 CST." Date: Fri, 09 Mar 2001 09:09:45 -0500 From: Thomas Narten 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 Again, summarizing on a number of postings... Jim.Bound@nokia.com writes: > Here is the taxonomy of the solution I can write up fully. Thomas please > respond especially (thanks). This looks basically fine to me. Good work. > A client cannot Renew or Rebind Temporary Addresses (they will be rejected > by the server). This would defeat the concerns in RFC 3041 > otherwise. I'm not sure we need to be totally absolute here. The idea behind temporary addresses is that in most cases, a connection won't last very long so a given temporary address shouldn't be valid for more than a few hours/days. However, if an application is using the address, what is the harm in continuing to use that address *by* *that* *one* *application*? I.e., it would be enough to deprecate the address but not invalidate it. Other applications opening connections would use a different temporary address. So it might make sense to allow the client extend a lease (and in particular to keep an address that is in active use from becoming invalid, which would result in termination of the connection), under the assumption that it knows what it is doing. Having said that, in practice, I'm not sure this will really be much of an issue. But do we want to shut the door? > Servers providing only Prefixes: > In a situation where a server only provides a prefix to the clients > link-local address then the above can still take place as discussed. Except > the responsibility and ownership of randomizing the link-local address IPv6 > EUI resides with the Client as stated for Stateless Addrconf in RFC 3041. > The dhcp lease provided to the client for Temporary addresses will still be > done by the server as stated in Server Providing Temporary Addresses > above. This might be the simplest to do, but I wonder if folks that deploy DHCP will like this model. I.e., clients will be using addresses that the server doesn't know about. If you are using DHCP to assign addresses, one reason might be so that the administrator knows exactly what addresses are being used and by whom. "Bernie Volz (EUD)" writes: >From my understanding, I still don't see the need for handling these >addresses specially. It really is a client issue (how it wants to >treat the address). Recall also that by specifying a different IA, a >client can request any number of addresses - since each IA represents >a new request. If a client wants a new address, it can simply >generate a new IA and request an address for that IA. If the IA space >(per client) is large enough, then if you want a new temporary >address every week, go for it (by simply requesting a new address via >a new IA). If the client wants to limit the time it uses an address, >it is always free to release it or let it expire (by not renewing >it). I'm not sure you want the client to have to use a different IA to request a new set of temporary addresses. One disadvantage is that when a client reboots, how does it indicate to the server that all the previous IAs it used are no longer needed and the server can release thos allocations? Earlier versions of DHCPv6 had a 'c' bit to handle this. It would be nice to avoid having that again. (more on this below.) "Bernie Volz (EUD)" writes: > Though I don't understand your response to my comment: > > [BV] A 'temporary' address request to the DHCPv6 server would mean > don't give me the same address for this IA that you might have given > me in the past and 'lease' the address for the temporary lease time > (not the full permanent address lease time). Is there any reason not to treat temporary address very similiar to the public (i.e., regular) addresses from the server perspective? I.e., the client can renew if it wants, etc. The *main* difference would be that the server should deprecate/invalidate the address (normally) after 1 day/1 week (using the 3041 suggested values). To get a new temporary address, the server treats it like a renumbering. Give both the old temporary address (which is perhaps deprecated) but also the new one (which is still valid). This is similiar to 3041 in that there is typically one temporary address in the preferred state, but a bunch of older ones in a deprecated state. > Are Releases for "temporary" addresses allowed if the client wants > to give up the address earlier? I'd say yes. I can't see a reason why not to allow this, and it might be useful. One example: A client reboots, requests temporary addresses, and gets a bunch of deprecated ones. The client (since it has rebooted) knows it has no connections using those addresses, so just releases them. Thomas From owner-dhcp-v6@bucknell.edu Fri Mar 9 09:22:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14647; Fri, 9 Mar 2001 09:22:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29ELpL29602; Fri, 9 Mar 2001 09:21:51 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29ELhL01157 for ; Fri, 9 Mar 2001 09:21:43 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f29EJGW04078 for ; Fri, 9 Mar 2001 09:19:16 -0500 Message-Id: <200103091419.f29EJGW04078@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: A proposal for DHCPv6 reconfiguration In-Reply-To: Message from Ralph Droms of "Tue, 27 Feb 2001 18:14:08 EST." <4.3.2.7.2.20010227181222.03515838@mail.bucknell.edu> Date: Fri, 09 Mar 2001 09:19:16 -0500 From: Thomas Narten 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 Droms writes: > Here's my proposal for server-initiated configuration, intended > to meet the listed goals (except for multicast authentication, > which I don't have a solution for): > Reliable unicast transmission can be managed through the use of the > transaction-id. The server includes a unique transaction ID in each > unicast Reconfigure-init message. The client responds to the first > Reconfigure-init message it receives, copying the transaction ID into > the Reply message the client sends to the server, and ignores all > subsequent Reconfigure-init messages with the same transaction ID. Unless I'm misunderstanding something basic, I don't think you want to do this. If the client's reply is lost, a simple server retransmission of the RI (request init) won't force the client to retransmit. I.e., the client has to wait much longer before being allowed to retransmit its Request. This isn't good protocol design. > This behavior causes the client to ignore duplicate copies of a single > Reconfigure-init message. If the server does not receive a Reply to > the Reconfigure-init with a matching transaction ID, the server can > try again by transmitting a new Reconfigure-init with a new > transaction ID. Why can't a client retransmit its request? What breaks? Indeed, the normal behavior is for clients to retransmit request messages. What is different here? The way I had been thinking about this is as follows: 1) Server sends a reconfigure with ID x. 2) Whenever a client gets a reconfigure for x, it records that and goes into a the state (sorry jim!) that means "time to contact the server again". In this state, the client retransmits the Request until it gets a RESPONSE. Note: this would seem to me to be exactly the same state as already exists in the DHCPv6 protocol as part of normal interactions with the server, so no new code 3) Client ignores all retransmissions of RECONFIG that have an id x that they already know about. But because step 2) includes retransmissions, ignoring retransmissions works fine. 4) The server doesn't need to see a Request with a particular XID (e.g., the one in the RI); what it looks for is a Request message from the client that was received more recently than when the first RI was sent. Does this make sense? Thomas From owner-dhcp-v6@bucknell.edu Fri Mar 9 10:32:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17536; Fri, 9 Mar 2001 10:32:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29FR0L02374; Fri, 9 Mar 2001 10:27:00 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29FQrL00664 for ; Fri, 9 Mar 2001 10:26:53 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29FQXg28434 for ; Fri, 9 Mar 2001 09:26:43 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 09:26:31 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 09:26:31 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Issue from San Diego IETF - temporary addresses Date: Fri, 9 Mar 2001 09:26:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Thomas, I think we are in synch now so lets solve the problem. thanks /jim > -----Original Message----- > From: ext Thomas Narten [mailto:narten@RALEIGH.IBM.COM] > Sent: Friday,March 09,2001 9:09 AM > To: DHCPv6 discussion list > Subject: Re: Issue from San Diego IETF - temporary addresses > > > Catching up on a number of postings.. > > Jim.Bound@nokia.com writes: > > > There is no way to differentiate a temp addr from other addr > > semantically. Please give us an example I don't see this in src > > addr select at all. In fact there are no bits in IPv6 addr arch > > anywhere to support this. > > I agree that there is no way to distinguish temporary addresses from > other ones by looking at them (i.e., syntactically). But there are > times when an implementation needs to know whether an address is > temporary or not. Hence, if DHCP is to be used to send temporary > addresses from the server to the client, there will need to be a way > to flag this. E.g., a bit in the extention. > > Note: the addr-select document in the ID directory is old. Per a note > to the IPNg list: > > "Richard Draves" writes: > > > I submitted these twelve hours before the deadline, but somehow they > > didn't get there in time: > > > > ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngw > g-default-addr-select-03.txt > > > ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipn > gwg-router-selection-01.txt > > Temporary addresses are described in the default-addr-select document. > > > Putting on my IPv6 hat I got to say that your statement that > > temporary addresses are part of the IPv6 address architecture is NOT > > TRUE. Its an appeasement for paranoids. > > I suspect we're having a disagreement over terminology more than > substance. Temporary addresses exist, they are part of the overall > IPv6 picture. Not everyone needs to implement them. But because they > are part of the overall picture, and they fit in with the existing > IPv6 architecture, I say they are part of the architecture. > > > > > > > There is a need for an API so that applications can > indicate if they > > > want to use a temporary vs. a "public" address, i.e., one > that that > > > doesn't change (or at least, doesn't change until there is a > > > renumbering event, etc.). That is still a TBD item in > IPNG and is not > > > something this WG needs to worry about too much. > > > This is just a knob an API is not needed. We have these > all over IPv6 > > implementations today. > > We're in agreement, just differing on terminology. I'm assuming "new > API" means extensions to the existing ones (i.e., the basic API). > > Note also that if an application can indicate (through the API) that > it does (or does not) want temporary addresses used, that is another > reason why such addresses must be distinguishable within an > implementation. I.e, source address selection indicates how to choose > temporary vs. public addresses when the application doesn't care, the > API is needed so that applications can override the defaults. > > > > > > > For nodes using stateless autoconfiguration, RFC 3041 > describes how > > > temporary addresses are created, when they expire, etc. DHCPv6, > > > because it can also be used to assign addresses to nodes, needs to > > > have a story on temporary addresses. That is, a node > should be able to > > > use temporary addresses regardless of whether stateless > or stateful > > > address autoconfiguration is needed. Thus, the DHCPv6 > spec needs to > > > say how temporary addresses are created and/or assigned > when DHCPv6 is > > > used. > > > This is not entirely correct. 3041 does not tell how to > create them but > > only how select that an address has a temporary context based on the > > lifetimes used for the addresses. By the way what is > unclear in 3041 is > > whether the router or the host alters the lifetimes. That > needs to be > > fixed. My assumption is that its the host and not the router. > > The host does the lifetimes. > > > Also none of this is mandatory for IPv6 or it would never > have gotten thru > > IPng or me. Recall our conversation about this at last > call? And as is > > pointed out in 3041: > > > Use of the extensions defined in this document may complicate > > debugging and other operational troubleshooting activities. > > Consequently, it may be site policy that temporary > addresses should > > not be used. Implementations may provide a method for a trusted > > administrator to override the use of temporary addresses. > > > > > > > Note that RFC 3041 makes it clear which addresses are > "temporary" and > > > which are not, and the address selection document > > > No they do not. What they do is give an algorithm to set > the lifetimes as > > follows using these constants: > > > TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able > > to override the default value. > > TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be > > able to override the default value. > > REGEN_ADVANCE -- 5 seconds > > MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. > > DESYNC_FACTOR -- A random value within the range 0 - > MAX_DESYNC_FACTOR. > > It is computed once at system start (rather than each time > > it is used) and must never be greater than > > (TEMP_VALID_LIFETIME - REGEN_ADVANCE). > > > As one who has written the code and shipped in the market > stateless addr > > conf one could set a bit or switch that once the algorithm > in 3041 is > > executed set a bit that this address has undergone the > processes to become > > temporary. > > > But to state that an IPv6 address can be identified for > example from tcpdump > > output by looking at the address as literal, hex, or binary > format is not > > true. > > We are miscommunicating, as I have never stated that one can identify > temporary addresses via tcpdump. > > > An address being temporary is a state and context in an > > implementation. > > I agree. But *if* DHCP supports temporary addresses by having the > server send them to the client, there would seem to need to be a way > for those addresses to be flagged as temporary. Stateless addrconf > doesn't have this issue because its all internal to the implementation > (e.g., not on the wire). > > Also, I'm not saying that DHCP has to support temporary addresses this > way. Another approach would be for the the DHCP server to send the > client the routing prefix and then have the host do everything else, > ala 3041. I wonder though if this is the "right" model in an > enviroment where DHCP is being used. I.e., presumably a site using > DHCP wants to know *ALL* the addresses that are in use and by whom, > and having the client generate them would not support this. This is > something the WG needs to work through. > > Note: I'm not responding to some of your other points because I think > they all result from a more basic disagreement that is addresses > earlier in this note. Those may need to be revisited if this note > isn't clarifying things. > > Thomas > From owner-dhcp-v6@bucknell.edu Fri Mar 9 11:23:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20353; Fri, 9 Mar 2001 11:23:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29GGwL06078; Fri, 9 Mar 2001 11:16:58 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29GGqL20863 for ; Fri, 9 Mar 2001 11:16:52 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29GGqg07114 for ; Fri, 9 Mar 2001 10:16:52 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 10:16:51 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 10:16:51 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Fri, 9 Mar 2001 10:16:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8B4.58ADF8F0" 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 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_001_01C0A8B4.58ADF8F0 Content-Type: text/plain; charset="iso-8859-1" Hi Bernie, Though I don't understand your response to my comment: [BV] A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). [JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph. [JPB2] Well Thomas suggested we not ruleout Renew. But for this draft I suggest we do and keep it very simple. The problem is that we do not want to permit an eaves dropper to determine anything from a temporary address bits on the wire. My response was saying there is more to supplying temporary addresses than just changing the lease. All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server: - Don't assign the same address(es) that might have been previously assigned for that IA. - Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.] - Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime). [JPB2] This is a good point about T1 and T2. We need to discuss. Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes. [JPB2] I would say yes too. >From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO. [JPB2] I believe a server MUST always respond to a client even if just error status. One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache. [JPB2] XID cached is an implementation option not required by dhcpv6. If the server gets a Request for Temporary address it reassigns them if no XID cache. I am pretty sure we have a good idempotent operation in the protocol for the Request message regardless of temp or public. PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances. [JPB2] We added it to the IA format see page 41. thanks /jim ------_=_NextPart_001_01C0A8B4.58ADF8F0 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
Hi Bernie,
 
Though I don't understand your response to my comment:
 
[BV] A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). 
 
[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
[JPB2]  Well Thomas suggested we not ruleout Renew.  But for this draft I suggest we do and keep it very simple.  The problem is that we do not want to permit an eaves dropper to determine anything from a temporary address bits on the wire.  My response was saying there is more to supplying temporary addresses than just changing the lease. 
 
All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server:
- Don't assign the same address(es) that might have been previously assigned for that IA.
- Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.]
- Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime).
[JPB2]  This is a good point about T1 and T2.  We need to discuss. 
 
Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes.
[JPB2] I would say yes too. 
 
From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO.
[JPB2] I believe a server MUST always respond to a client even if just error status. 
 
One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache.
[JPB2] XID cached is an implementation option not required by dhcpv6.  If the server gets a Request for Temporary address it reassigns them if no XID cache.  I am pretty sure we have a good idempotent operation in the protocol for the Request message regardless of temp or public. 
 
PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances.
[JPB2] We added it to the IA format see page 41.
 
thanks
/jim 
 
------_=_NextPart_001_01C0A8B4.58ADF8F0-- From owner-dhcp-v6@bucknell.edu Fri Mar 9 11:29:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20624; Fri, 9 Mar 2001 11:29:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29GSIL14072; Fri, 9 Mar 2001 11:28:18 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29GS9L18869 for ; Fri, 9 Mar 2001 11:28:09 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29GRog11418 for ; Fri, 9 Mar 2001 10:28:00 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 10:27:49 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 10:27:49 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Server address assignment policies Re: [was: Temporary Addres s Solution] Date: Fri, 9 Mar 2001 10:27:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Thomas, > My take would be that the document should explain that how it assigns > addresses is an important topic with interesting implications, and > give suggestions on what a server should do. It might even make sense > to recommend that server support a number of ways of assiging > addresses (e.g., just use EUI-64 for interface ID, use random numbers, > number sequentially starting at 1, etc.), with knobs in a config file > for selecting which policy one wants. > > Thomas > Can you be more clear here. I may have to push back hard on this suggestion. It has and always should be how any server implementation sets up its database or configures how it assigns addresses is implementation specific. I am highly confident all implementors will agree with me. But I do not think your asking us to do this? Another thing that you may be asking is a simple statement that a server should support multiple address scenarios as an editorial comment. If its just an editorial comment you are suggesting I am fine with that. But we cannot and should not mandate anything on the above in an IETF server to client protocol. I guess its not clear to me what your asking for here. regards, /jim From owner-dhcp-v6@bucknell.edu Fri Mar 9 11:38:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21256; Fri, 9 Mar 2001 11:38:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29GbSL15457; Fri, 9 Mar 2001 11:37:28 -0500 (EST) 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 f29GbIL02736 for ; Fri, 9 Mar 2001 11:37:18 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA22770 for ; Fri, 9 Mar 2001 11:36:59 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA36776 for ; Fri, 9 Mar 2001 11:37:02 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA20733 for ; Fri, 9 Mar 2001 11:36:18 -0500 Message-Id: <200103091636.LAA20733@rotala.raleigh.ibm.com> To: DHCPv6 discussion list Subject: Re: Server address assignment policies Re: [was: Temporary Addres s Solution] In-Reply-To: Message from Jim.Bound@nokia.com of "Fri, 09 Mar 2001 10:27:46 CST." Date: Fri, 09 Mar 2001 11:36:18 -0500 From: Thomas Narten 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, > It has and always should be how any server implementation sets up its > database or configures how it assigns addresses is implementation specific. > I am highly confident all implementors will agree with me. But I do not > think your asking us to do this? I think it makes sense to ask the question whether it should just be left to implementations (saying very little) or whether the WG thinks it a good idea to describe some possible implementations (and when I say implementations, I'm really saying behaviors on how addresses are assigned, e.g., random vs sequential addresses vs. something else). The WG might also think it good to not just describe the possibilities but recommend those that a server (say) SHOULD provide. I'd really like to get a perspective here from folks that are shipping DHCPv4 servers today and whether this makes sense. Also, I'm asking, not saying. Thomas From owner-dhcp-v6@bucknell.edu Fri Mar 9 12:04:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22829; Fri, 9 Mar 2001 12:04:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29H1qL06990; Fri, 9 Mar 2001 12:01:52 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29H1iL07223 for ; Fri, 9 Mar 2001 12:01:44 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29H1jg18648 for ; Fri, 9 Mar 2001 11:01:45 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 11:01:44 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 11:01:44 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Server address assignment policies Re: [was: Temporary Addres s Solution] Date: Fri, 9 Mar 2001 10:59:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 am ok with that. But... my concern is that the IETF in any part of our community TELL USERS WHAT TO DO. That is unacceptable. Thats all I am saying. Its the users business what they want to do with what we develop. They pay the bills. Without them are role is irrelevant. One user will want to use Ipv6 addresses one way another user another way. If we do anything that does not permit that freedom of choice then we are crossing a line from building standards to telling users what they get. That being said the options we give them must be possible to implement in a scalable manner, be interoperable across multiple vendors, etc... Thats fine. It the fine line we need to be careful of here is my concern. /jim > -----Original Message----- > From: ext Thomas Narten [mailto:narten@RALEIGH.IBM.COM] > Sent: Friday,March 09,2001 11:36 AM > To: DHCPv6 discussion list > Subject: Re: Server address assignment policies Re: [was: Temporary > Addres s Solution] > > > Jim, > > > It has and always should be how any server implementation > sets up its > > database or configures how it assigns addresses is > implementation specific. > > I am highly confident all implementors will agree with me. > But I do not > > think your asking us to do this? > > I think it makes sense to ask the question whether it should just be > left to implementations (saying very little) or whether the WG thinks > it a good idea to describe some possible implementations (and when I > say implementations, I'm really saying behaviors on how addresses are > assigned, e.g., random vs sequential addresses vs. something > else). The WG might also think it good to not just describe the > possibilities but recommend those that a server (say) SHOULD provide. > > I'd really like to get a perspective here from folks that are shipping > DHCPv4 servers today and whether this makes sense. > > Also, I'm asking, not saying. > > Thomas > From owner-dhcp-v6@bucknell.edu Fri Mar 9 12:32:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24689; Fri, 9 Mar 2001 12:32:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29HVHL15968; Fri, 9 Mar 2001 12:31:17 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29HVAL16349 for ; Fri, 9 Mar 2001 12:31:10 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f29HUpg23842 for ; Fri, 9 Mar 2001 11:31:01 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Mar 2001 11:30:49 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 9 Mar 2001 11:30:49 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Issue from San Diego IETF - temporary addresses Date: Fri, 9 Mar 2001 11:30:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Thomas, > "Richard Draves" writes: > > > I submitted these twelve hours before the deadline, but somehow they > > didn't get there in time: > > > > ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngw > g-default-addr-select-03.txt > > > ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipn > gwg-router-selection-01.txt > > Temporary addresses are described in the default-addr-select document Not guy. No change in wording. Just points to rfc 3041. We have just done more in the dhcpv6 to support I think what someone wants than anywhere else in the ietf. Next mail is to IPng where I will vehemently object to temporary addresses being preferred over public addresses. /jim > From owner-dhcp-v6@bucknell.edu Fri Mar 9 14:47:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01779; Fri, 9 Mar 2001 14:47:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29JkjL24790; Fri, 9 Mar 2001 14:46:45 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29JkTL24780 for ; Fri, 9 Mar 2001 14:46:29 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f29JkRi19276 for ; Fri, 9 Mar 2001 13:46:27 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f29JkRl01350 for ; Fri, 9 Mar 2001 13:46:27 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Mar 09 13:48:04 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 13:48:01 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F6566@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Server address assignment policies Re: [was: Temporary Addres s Solution] Date: Fri, 9 Mar 2001 13:47:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8D1.D428AA80" 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 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_001_01C0A8D1.D428AA80 Content-Type: text/plain; charset="iso-8859-1" Jim/Thomas: Since I'm responsible for raising this issue, let me say that all I was after is providing some guidelines on how a server is supposed to select addresses. Only guidelines, such as "A server "MAY" assign addresses using any mechanism but what follows is a discussion of possible techniques and their implications ...". This might include a discussion about whether to set or clear the "u" (universal/local) bit based on how the address is generated (see RFC 2373, Section 2.5.1). DHCPv6 servers might also be given only a 'range' of addresses to use (rather than the entire 'lower' 64-bits (interface identifier bits). This means that using a EUI64 identifier isn't possible (or at least not all 64-bits of it). And, consider what RFC 3041 says: "One way to avoid some of the problems discussed above is to use DHCP for obtaining addresses. With DHCP, the DHCP server could arrange to hand out addresses that change over time." Here it assumes that DHCPv6 servers would have a knob to "arrange to hand out addresses that changed over time". So, wouldn't we want to document this or at least draw some attention to it? - Bernie Volz -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 09, 2001 12:00 PM To: DHCPv6 discussion list Subject: RE: Server address assignment policies Re: [was: Temporary Addres s Solution] I am ok with that. But... my concern is that the IETF in any part of our community TELL USERS WHAT TO DO. That is unacceptable. Thats all I am saying. Its the users business what they want to do with what we develop. They pay the bills. Without them are role is irrelevant. One user will want to use Ipv6 addresses one way another user another way. If we do anything that does not permit that freedom of choice then we are crossing a line from building standards to telling users what they get. That being said the options we give them must be possible to implement in a scalable manner, be interoperable across multiple vendors, etc... Thats fine. It the fine line we need to be careful of here is my concern. /jim > -----Original Message----- > From: ext Thomas Narten [mailto:narten@RALEIGH.IBM.COM] > Sent: Friday,March 09,2001 11:36 AM > To: DHCPv6 discussion list > Subject: Re: Server address assignment policies Re: [was: Temporary > Addres s Solution] > > > Jim, > > > It has and always should be how any server implementation > sets up its > > database or configures how it assigns addresses is > implementation specific. > > I am highly confident all implementors will agree with me. > But I do not > > think your asking us to do this? > > I think it makes sense to ask the question whether it should just be > left to implementations (saying very little) or whether the WG thinks > it a good idea to describe some possible implementations (and when I > say implementations, I'm really saying behaviors on how addresses are > assigned, e.g., random vs sequential addresses vs. something > else). The WG might also think it good to not just describe the > possibilities but recommend those that a server (say) SHOULD provide. > > I'd really like to get a perspective here from folks that are shipping > DHCPv4 servers today and whether this makes sense. > > Also, I'm asking, not saying. > > Thomas > ------_=_NextPart_001_01C0A8D1.D428AA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Server address assignment policies Re: [was: Temporary = Addres s Solution]

Jim/Thomas:

Since I'm responsible for raising this issue, let me = say that all I was after is providing some guidelines on how a server = is supposed to select addresses. Only guidelines, such as "A = server "MAY" assign addresses using any mechanism but what = follows is a discussion of possible techniques and their implications = ...". This might include a discussion about whether to set or = clear the "u" (universal/local) bit based on how the address = is generated (see RFC 2373, Section 2.5.1). DHCPv6 servers might also = be given only a 'range' of addresses to use (rather than the entire = 'lower' 64-bits (interface identifier bits). This means that using a = EUI64 identifier isn't possible (or at least not all 64-bits of = it).

And, consider what RFC 3041 says:
"One way to avoid some of the problems = discussed above is to use DHCP for obtaining addresses.  With = DHCP, the DHCP server could arrange to hand out addresses that change = over time."

Here it assumes that DHCPv6 servers would have a knob = to "arrange to hand out addresses that changed over time". = So, wouldn't we want to document this or at least draw some attention = to it?

- Bernie Volz

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 09, 2001 12:00 PM
To: DHCPv6 discussion list
Subject: RE: Server address assignment policies Re: = [was: Temporary
Addres s Solution]


I am ok with that.  But... my concern is that = the IETF in any part of our
community TELL USERS WHAT TO DO.  That is = unacceptable.  Thats all I am
saying.  Its the users business what they want = to do with what we develop.
They pay the bills.  Without them are role is = irrelevant.  One user will
want to use Ipv6 addresses one way another user = another way.  If we do
anything that does not permit that freedom of choice = then we are crossing a
line from building standards to telling users what = they get.  That being
said the options we give them must be possible to = implement in a scalable
manner, be interoperable across multiple vendors, = etc...  Thats fine.  It
the fine line we need to be careful of here is my = concern.

/jim

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten@RALEIGH.IBM.COM= ]
> Sent: Friday,March 09,2001 11:36 AM
> To: DHCPv6 discussion list
> Subject: Re: Server address assignment policies = Re: [was: Temporary
> Addres s Solution]
>
>
> Jim,
>
> > It has and always should be how any server = implementation
> sets up its
> > database or configures how it assigns = addresses is
> implementation specific.
> > I am highly confident all implementors = will agree with me. 
>  But I do not
> > think your asking us to do this?
>
> I think it makes sense to ask the question = whether it should just be
> left to implementations (saying very little) or = whether the WG thinks
> it a good idea to describe some possible = implementations (and when I
> say implementations, I'm really saying = behaviors on how addresses are
> assigned, e.g., random vs sequential addresses = vs. something
> else). The WG might also think it good to not = just describe the
> possibilities but recommend those that a server = (say) SHOULD provide.
>
> I'd really like to get a perspective here from = folks that are shipping
> DHCPv4 servers today and whether this makes = sense.
>
> Also, I'm asking, not saying.
>
> Thomas
>

------_=_NextPart_001_01C0A8D1.D428AA80-- From owner-dhcp-v6@bucknell.edu Fri Mar 9 16:44:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06088; Fri, 9 Mar 2001 16:44:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29LabL27409; Fri, 9 Mar 2001 16:36:37 -0500 (EST) 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 f29LaPL16721 for ; Fri, 9 Mar 2001 16:36:25 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp133-156.cisco.com [161.44.133.156]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20432 for ; Fri, 9 Mar 2001 16:36:09 -0500 (EST) Message-Id: <4.3.2.7.2.20010309155917.032a4ee8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 16:36:01 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHCPv6 spec and design team meeting 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 completed a -18 rev of the DHCPv6 spec, with changes based on comments by Francis DuPont. I submitted it to the IETF and received an ack, but it hasn't been announced. Until it's available at ietf.org, you can get a copy at www.dhcp.org. There will be a design team teleconference to discuss the remaining open issues in the spec on Wednesday, March 14 from noon to 3PM EST. Cisco will arrange for phone conferencing and will be happy to reimburse anyone for phone expenses incurred in joining the conference. Please contact me for information about participating in the teleconference. Here's a tentative bullet list of discussion topics for the 3/14 teleconference: * IA identification - globally unique DUID scheme - identify IA by or DUID * Reconfigure - authentication semantics (Narten proposal) - multicast reconfigure authentication * Anonymous addresses * Additional options - What options are required in base spec? - Delete control of operational parameters by server - Ralph From owner-dhcp-v6@bucknell.edu Fri Mar 9 16:51:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06321; Fri, 9 Mar 2001 16:51:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f29LjcL10156; Fri, 9 Mar 2001 16:45:38 -0500 (EST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f29LjWL25467 for ; Fri, 9 Mar 2001 16:45:32 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 9 Mar 2001 13:46:04 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Mar 2001 13:46:03 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 9 Mar 2001 13:46:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4663.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DHCPv6 spec and design team meeting Date: Fri, 9 Mar 2001 13:46:02 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A688C59F7@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: DHCPv6 spec and design team meeting Thread-Index: AcCo4ar1gC8DaX/QRbO1ptwfyzRncwAAHS9A From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 09 Mar 2001 21:46:03.0031 (UTC) FILETIME=[564C9A70:01C0A8E2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f29LjWL26265 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: 8bit Ralph, I and a couple of others here are interested in joining this teleconference. Let me know the teleconference number. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, March 09, 2001 1:36 PM To: DHCPv6 discussion list Subject: DHCPv6 spec and design team meeting I completed a -18 rev of the DHCPv6 spec, with changes based on comments by Francis DuPont. I submitted it to the IETF and received an ack, but it hasn't been announced. Until it's available at ietf.org, you can get a copy at www.dhcp.org. There will be a design team teleconference to discuss the remaining open issues in the spec on Wednesday, March 14 from noon to 3PM EST. Cisco will arrange for phone conferencing and will be happy to reimburse anyone for phone expenses incurred in joining the conference. Please contact me for information about participating in the teleconference. Here's a tentative bullet list of discussion topics for the 3/14 teleconference: * IA identification - globally unique DUID scheme - identify IA by or DUID * Reconfigure - authentication semantics (Narten proposal) - multicast reconfigure authentication * Anonymous addresses * Additional options - What options are required in base spec? - Delete control of operational parameters by server - Ralph From owner-dhcp-v6@bucknell.edu Sun Mar 11 23:43:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19709; Sun, 11 Mar 2001 23:43:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2C4diL21943; Sun, 11 Mar 2001 23:39:45 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2C4dgL22692 for ; Sun, 11 Mar 2001 23:39:42 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2C4dei26252 for ; Sun, 11 Mar 2001 22:39:41 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2C4der29911 for ; Sun, 11 Mar 2001 22:39:40 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Sun Mar 11 22:41:18 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 11 Mar 2001 22:41:18 -0600 Message-ID: <66F66129A77AD411B76200508B65AC693540B5@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Date: Sun, 11 Mar 2001 22:41:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AAAE.AD673EF0" 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 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_001_01C0AAAE.AD673EF0 Content-Type: text/plain; charset="iso-8859-1" Jim: PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances. [JPB2] We added it to the IA format see page 41. [BV2] Yes, but all it says is "addr status Status of this address." So, is this an error value (from section 7.4) or is this a flag bits (that type of status), such as this address is a temporary address (which is I think what you wanted to use it for). Perhaps one could have it both ways (success & public address = 00 and success & temporary address = 01), but I suspect we'll find that will get us into trouble. Or, are you thinking of adding another field to the addresses in an IA Option to use for this purpose? Or did I misunderstand you? - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 09, 2001 11:17 AM To: DHCPv6 discussion list Subject: RE: Temporary Address Solution Hi Bernie, Though I don't understand your response to my comment: [BV] A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). [JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph. [JPB2] Well Thomas suggested we not ruleout Renew. But for this draft I suggest we do and keep it very simple. The problem is that we do not want to permit an eaves dropper to determine anything from a temporary address bits on the wire. My response was saying there is more to supplying temporary addresses than just changing the lease. All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server: - Don't assign the same address(es) that might have been previously assigned for that IA. - Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.] - Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime). [JPB2] This is a good point about T1 and T2. We need to discuss. Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes. [JPB2] I would say yes too. >From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO. [JPB2] I believe a server MUST always respond to a client even if just error status. One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache. [JPB2] XID cached is an implementation option not required by dhcpv6. If the server gets a Request for Temporary address it reassigns them if no XID cache. I am pretty sure we have a good idempotent operation in the protocol for the Request message regardless of temp or public. PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances. [JPB2] We added it to the IA format see page 41. thanks /jim ------_=_NextPart_001_01C0AAAE.AD673EF0 Content-Type: text/html; charset="iso-8859-1" RE: Temporary Address Solution
Jim:
 
PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances.
[JPB2] We added it to the IA format see page 41.
 
[BV2] Yes, but all it says is "addr status  Status of this address." So, is this an error value (from section 7.4) or is this a flag bits (that type of status), such as this address is a temporary address (which is I think what you wanted to use it for). Perhaps one could have it both ways (success & public address = 00 and success & temporary address = 01), but I suspect we'll find that will get us into trouble. Or, are you thinking of adding another field to the addresses in an IA Option to use for this purpose? Or did I misunderstand you?
 
- Bernie
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 09, 2001 11:17 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Hi Bernie,
 
Though I don't understand your response to my comment:
 
[BV] A 'temporary' address request to the DHCPv6 server would mean don't give me the same address for this IA that you might have given me in the past and 'lease' the address for the temporary lease time (not the full permanent address lease time). 
 
[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
[JPB2]  Well Thomas suggested we not ruleout Renew.  But for this draft I suggest we do and keep it very simple.  The problem is that we do not want to permit an eaves dropper to determine anything from a temporary address bits on the wire.  My response was saying there is more to supplying temporary addresses than just changing the lease. 
 
All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server:
- Don't assign the same address(es) that might have been previously assigned for that IA.
- Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.]
- Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime).
[JPB2]  This is a good point about T1 and T2.  We need to discuss. 
 
Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes.
[JPB2] I would say yes too. 
 
From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO.
[JPB2] I believe a server MUST always respond to a client even if just error status. 
 
One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache.
[JPB2] XID cached is an implementation option not required by dhcpv6.  If the server gets a Request for Temporary address it reassigns them if no XID cache.  I am pretty sure we have a good idempotent operation in the protocol for the Request message regardless of temp or public. 
 
PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances.
[JPB2] We added it to the IA format see page 41.
 
thanks
/jim 
 
------_=_NextPart_001_01C0AAAE.AD673EF0-- From owner-dhcp-v6@bucknell.edu Sun Mar 11 23:44:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19752; Sun, 11 Mar 2001 23:44:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2C4fCL09208; Sun, 11 Mar 2001 23:41:12 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2C4dgL02454 for ; Sun, 11 Mar 2001 23:39:42 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2C4dfi26256 for ; Sun, 11 Mar 2001 22:39:42 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2C4dfr29915 for ; Sun, 11 Mar 2001 22:39:41 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Mar 11 22:41:20 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 11 Mar 2001 22:41:20 -0600 Message-ID: <66F66129A77AD411B76200508B65AC693540B6@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A proposal for DHCPv6 reconfiguration Date: Sun, 11 Mar 2001 22:41:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AAAE.AE641580" 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 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_001_01C0AAAE.AE641580 Content-Type: text/plain; charset="iso-8859-1" Thomas ... I think it does. It also gets rid of the nasty problem with having clients pick up and use the server's transaction-id, which could collide with one of the client's own choosing (I had suggested we use a RECONFIG-XID option to communicate that in the Request but no need now). I was reading the -18 draft and re-read this and I think this does solve the problem nicely. Who cares why the Request came in is correct - it really doesn't matter (as long as the request happened after the Reconfigure-Init, as you say). Now I have to go change my comments on the -18 draft to reflect this. There is, however, one minor issue we probably should discuss. By using the Request message type, we're really overloading this to mean "Give me (new) addresses" and "Reconfigure requested, what's new?". (We unloaded it from meaning Renew, Rebind, & Confirm). Perhaps we should not use the Request message and instead define a new one - Reconfigure-Request or some such name. This would essentially be identical to how the Request is used now for Reconfigure-Init, but would be clear to the server that the client has receive the Reconfigure-Init request. (The server SHOULD also consider any Request messages received from clients that arrive after the Reconfigure-Init to flag that client as having responded to the Reconfigure-Init; whether it actually did or not, is immaterial.) - Bernie Volz -----Original Message----- From: Thomas Narten [mailto:narten@RALEIGH.IBM.COM] Sent: Friday, March 09, 2001 9:19 AM To: DHCPv6 discussion list Subject: Re: A proposal for DHCPv6 reconfiguration Ralph Droms writes: > Here's my proposal for server-initiated configuration, intended > to meet the listed goals (except for multicast authentication, > which I don't have a solution for): > Reliable unicast transmission can be managed through the use of the > transaction-id. The server includes a unique transaction ID in each > unicast Reconfigure-init message. The client responds to the first > Reconfigure-init message it receives, copying the transaction ID into > the Reply message the client sends to the server, and ignores all > subsequent Reconfigure-init messages with the same transaction ID. Unless I'm misunderstanding something basic, I don't think you want to do this. If the client's reply is lost, a simple server retransmission of the RI (request init) won't force the client to retransmit. I.e., the client has to wait much longer before being allowed to retransmit its Request. This isn't good protocol design. > This behavior causes the client to ignore duplicate copies of a single > Reconfigure-init message. If the server does not receive a Reply to > the Reconfigure-init with a matching transaction ID, the server can > try again by transmitting a new Reconfigure-init with a new > transaction ID. Why can't a client retransmit its request? What breaks? Indeed, the normal behavior is for clients to retransmit request messages. What is different here? The way I had been thinking about this is as follows: 1) Server sends a reconfigure with ID x. 2) Whenever a client gets a reconfigure for x, it records that and goes into a the state (sorry jim!) that means "time to contact the server again". In this state, the client retransmits the Request until it gets a RESPONSE. Note: this would seem to me to be exactly the same state as already exists in the DHCPv6 protocol as part of normal interactions with the server, so no new code 3) Client ignores all retransmissions of RECONFIG that have an id x that they already know about. But because step 2) includes retransmissions, ignoring retransmissions works fine. 4) The server doesn't need to see a Request with a particular XID (e.g., the one in the RI); what it looks for is a Request message from the client that was received more recently than when the first RI was sent. Does this make sense? Thomas ------_=_NextPart_001_01C0AAAE.AE641580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A proposal for DHCPv6 reconfiguration

Thomas ... I think it does. It also gets rid of the = nasty problem with having clients pick up and use the server's = transaction-id, which could collide with one of the client's own = choosing (I had suggested we use a RECONFIG-XID option to communicate = that in the Request but no need now).

I was reading the -18 draft and re-read this and I = think this does solve the problem nicely. Who cares why the Request = came in is correct - it really doesn't matter (as long as the request = happened after the Reconfigure-Init, as you say).

Now I have to go change my comments on the -18 draft = to reflect this.

There is, however, one minor issue we probably should = discuss. By using the Request message type, we're really overloading = this to mean "Give me (new) addresses" and "Reconfigure = requested, what's new?". (We unloaded it from meaning Renew, = Rebind, & Confirm). Perhaps we should not use the Request message = and instead define a new one - Reconfigure-Request or some such name. = This would essentially be identical to how the Request is used now for = Reconfigure-Init, but would be clear to the server that the client has = receive the Reconfigure-Init request. (The server SHOULD also consider = any Request messages received from clients that arrive after the = Reconfigure-Init to flag that client as having responded to the = Reconfigure-Init; whether it actually did or not, is = immaterial.)

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:narten@RALEIGH.IBM.COM= ]
Sent: Friday, March 09, 2001 9:19 AM
To: DHCPv6 discussion list
Subject: Re: A proposal for DHCPv6 reconfiguration =


Ralph Droms <droms@bucknell.edu> writes:

> Here's my proposal for server-initiated = configuration, intended
> to meet the listed goals (except for multicast = authentication,
> which I don't have a solution for):

> Reliable unicast transmission can be managed = through the use of the
> transaction-id.  The server includes a = unique transaction ID in each
> unicast Reconfigure-init message.  The = client responds to the first
> Reconfigure-init message it receives, copying = the transaction ID into
> the Reply message the client sends to the = server, and ignores all
> subsequent Reconfigure-init messages with the = same transaction ID.

Unless I'm misunderstanding something basic, I don't = think you want to
do this. If the client's reply is lost, a simple = server retransmission
of the RI (request init) won't force the client to = retransmit. I.e.,
the client has to wait much longer before being = allowed to retransmit
its Request. This isn't good protocol design.

> This behavior causes the client to ignore = duplicate copies of a single
> Reconfigure-init message.  If the server = does not receive a Reply to
> the Reconfigure-init with a matching = transaction ID, the server can
> try again by transmitting a new = Reconfigure-init with a new
> transaction ID.

Why can't a client retransmit its request? What = breaks? Indeed, the
normal behavior is for clients to retransmit request = messages. What is
different here?

The way I had been thinking about this is as = follows:

1) Server sends a reconfigure with ID x.

2) Whenever a client gets a reconfigure for x, it = records that and
   goes into a the state (sorry jim!) that = means "time to contact the
   server again". In this state, the = client retransmits the Request
   until it gets a RESPONSE. Note: this = would seem to me to be exactly
   the same state as already exists in the = DHCPv6 protocol as part of
   normal interactions with the server, so = no new code
  
3) Client ignores all retransmissions of RECONFIG = that have an id x
   that they already know about. But = because step 2) includes
   retransmissions, ignoring = retransmissions works fine.

4) The server doesn't need to see a Request with a = particular XID
   (e.g., the one in the RI); what it = looks for is a Request message
   from the client that was received more = recently than when the first
   RI was sent.

Does this make sense?

Thomas

------_=_NextPart_001_01C0AAAE.AE641580-- From owner-dhcp-v6@bucknell.edu Mon Mar 12 19:09:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25188; Mon, 12 Mar 2001 19:09:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2D04eL13491; Mon, 12 Mar 2001 19:04:40 -0500 (EST) 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 f2D03nL28046 for ; Mon, 12 Mar 2001 19:04:31 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel3.hp.com (Postfix) with ESMTP id A5F03C1A for ; Mon, 12 Mar 2001 16:03:39 -0800 (PST) Received: from india.hp.com (vijayak@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 FAA03009 for ; Tue, 13 Mar 2001 05:31:29 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3AAD645C.52469B45@india.hp.com> Date: Tue, 13 Mar 2001 05:35:48 +0530 From: Vijay Bhaskar A K Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: questions on DHCPv6 -18 rev of draft 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 Hi, I have few questions regarding the -18 rev of DHCPv6 draft. I will be attending the design telecon. let me know your comments about these issues. Regrads, Vijay questions --------- * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 implmentation has to take care of the fragmentation. Assume the client has fragmented the packet in to two packets. The server will read the first packet correctly, since it is in proper packet format. Then, the second packet will be discarded, since it has only the remaining content of the previously sent packet. This is because, the server doesn't know that whether the packet recieved is correct one or the later part of the prviously sent fragmented packet. Do we need to have an additional message type (or) a field speciying the "next fragment" for transmission of the fragemented packet? * How DUID is generated? what is its format? * I think we don't need site scoped "All DHCP Clients" multicast address for sending reconfigure messages. Since, renumbering of network takes place per link basis. This means we need to send Reconfigure message to only the nodes in a particular link, not to all the nodes in the site. Thus, if we use All DHCP clients multicast address, most of the nodes will unecessarily receive the Reconfigure-init message. * There are some list of Generic Error values like AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned how to return this error value. We need an option or a field for returning these generic error values. This option must be included in the base-spec. * In solicit message, does the client need to send the number of IP address needed for the IA, in the IA option? I think it is better to send the requested number of IP address in the Ia option. If the client is asking "n" number of IP address and the server can offer only "m" IP-addresses (mThe server MUST include options to Advertise message containing any address >that would be assigned to IAs contained in the Solicit message format. 1. Is this similar to the DHCP OFFER in DHCPv4? 2. If the client has asked "n" IP address, does the server need to send "n" address in the IA? (or) need to send the just the prefix? 3. If the server does not have one or few of the requested configuration parameters asked by the client in ORO option, does the server need to send the only the configuration parameters it have and leave the other options. (or) since it doesn't have some of the configuration parameters, will it tollaly ignore the Solicit and don't send reply? 4. If the server can offer only few IP-address (m) less than the requested number of IP-address (n), does the server needs to respond with the available number of IP-address (OR) doesn't send Advertise? 5. If the server is sending the "n" IP Addresses in IA option in Advertise message, it means that, these addresses should not be assigned to the other clients and is reserved for the client that has sent the Solicit? Request message _______________ 1. assume, the client has asked 2 IP address first time. After some times, it needs another 3 IP-address in the same interface. This time, does it need to send a fresh empty IA? or it can ask for another 3 IP-address in the same IA? a) If it has to send the fresh empty IA, how will the server maintain the record of these IAs, since the IA sent at the first time and sent next time will have the same DUID and subnet-prefix. Will the server treat these two as different or same IAs? b) why empty IA is to be sent for requesting IP address? c) what does exactly the empty IA mean? In other words, what are the fields to be filled in IA options for sending the empty IA. (eg):- If the client is requesting 3 IP-address, I think these are fields which must be filled. (1) option-code (2) option-len (3) IA-DUID (4) num-addrs = 3 do the addr status, prefix length, IPv6 address, pref life time, val life time should be present or filled with zeros? 2. If the client has sufficient scope to reach the server, then why can't it send the Request message directly? Why is it mentioned in the draft that it should send the Request message to All DHCP Agents Address? This situtation holds for renew and rebind message also. Release Message _______________ For sending DHCP Release message, does the client include addresses to be released? (or) includes ONLY the address to be released? Authentication Option _____________________ Why authentication option is to be included as the last option? If it is included as the first option, it will be easier to authenicate first and in case, if authentication fails, it can directly reject the packet without processing further. Sending deprecated address __________________________ Assume 1. A network renumbering for a particular link has occured. The prefix 5ffe:: is changed to 3ffe:: 2. An IA for a node in this link has following addresses, 5ffe::20 and 5ffe::21 3. Now reconfiguration has been triggered and the server has sent the Reconfigure-init message to the client. 4. Client has responded with DHCP Request. a) does the server has to delete the addresses 5ffe::20 and 5ffe::21 from the IA and include 3ffe::20 and 3ffe:21 in the IA? (or) b) for graceful renumbering, it can add new IP-address 3ffe::20 and 3ffe:21 to the IA along with the orginal 5ffe addresses? In this case, i feel that the old prefix addresses (5ffe) should be made deprecated one with the prefered-lifetime = 0 and valid-lifetime = some grace period. I think this is a MUST one for renumbering. _______________________ * In the draft, in one section(12.3.2) , it is mentioned that, client has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In another section( WAIT collecting Advertise message. Since both the variable has different default values, which is to be used? From owner-dhcp-v6@bucknell.edu Mon Mar 12 19:44:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26123; Mon, 12 Mar 2001 19:44:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2D0fEL09617; Mon, 12 Mar 2001 19:41:14 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2D0ewL14391 for ; Mon, 12 Mar 2001 19:40:58 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2D0evi28187 for ; Mon, 12 Mar 2001 18:40:57 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2D0evF02719 for ; Mon, 12 Mar 2001 18:40:57 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Mar 12 18:42:38 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Mar 2001 18:42:37 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F6582@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: questions on DHCPv6 -18 rev of draft Date: Mon, 12 Mar 2001 18:42:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB56.7E2ADF90" 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 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_001_01C0AB56.7E2ADF90 Content-Type: text/plain; charset="iso-8859-1" Some comments regarding your questions: Fragmentation - This problem doesn't exist. The IPv6 layer will reassemble the packet. If the packet is multicast on the link, the other systems on that link in the destination multicast group will all reassemble the packet before processing it. So, whether it is a relay agent or a server doesn't matter. Also, if the relay is unicasting the packet to a server, same thing happens (it will be reassembled). This fragmentation is NOT something that the DHCP Client code does - but something that happens at the IPv6 layer. So, if the -18 text isn't clear about this, we need to fix it. DUID - How it is generated is still the $64,000 question. There have been some proposals in discussions. All DHCP Clients Multicast - I agree, it should be link local. This hasn't yet been fully explored. It appears, from the -18 draft, that the server somehow communicates the client to tell it what Multicast group to join, but I think that has flaws in it. (I'm in the process of writing up some review comments as well in preparation for the conference call and this was one of my issues.) Solicit message - The client just sends whatever IA option(s) it would send with a Request. This allows the server to respond with what it would assign on receipt of the Request. And, yes this is very similar to the DHCP DISCOVER/OFFER. The reason is that the client may need this information to make a decision as to which Advertise it will accept. Note that the specification (12.3.1) says: "all of the IAs MUST be empty" (when creating the Solicit). I believe that the server should reply even if it can't honor all of the options in the ORO - the client can decide which to take based on what it receives (if it needs a particular option, it can discard the ones without it). That's what we do in DHCPv4. If the server Advertises addresses, it should behave similar to DHCPv4's OFFER in that the server SHOULD not reassign these addresses for a short time to 'reserve' them for the client. But, it is only a SHOULD and not a MUST (the server may change the addresses in the REPLY). Note that when the Client constructs the Request "The list of addresses in each included IA MUST be empty." (13.3.1). Therefore, unless the server takes steps to 'reserve' the addresses, the client should have forgotten about them. Request message (client wants more addresss) - If a client wants new addresses, it must use a new IA. This new DUID must be different than the previous. The DUID really is a client identifier/interface identifier/address request identifier. I think this has gotten lost in the draft text. The reason for sending *ALL* client requests via the multicast mechanism is such that if a relay agent is between the client and server IT WILL ALWAYS BE between the client and server. Therefore, things like the DHCPv4 Relay Agent options can always be inserted in the clients requests and the server always has complete information. This is actually a nice solution. There are also others (such as if there are failover partners, they can respond on behalf of each other if they know the target server is down). There is of course a cost, but it is rather low. One option we could consider (though at the lost of some potential features such as the failover one) is allowing a client to unicast to the server IF AND ONLY IF the server is on the link (ie, the server's address is a link-local). For in that case, no relay options would be added. But, I'm not in favor of this. Release message - A client can release one or many addresses (either in one or multiple IAs). It need not release all of the addresses in a single IA. Sending deprecated address - I would expect that the server to do (b) - include both the old addresses (with lifetimes adjusted) and the new. However, it may also do (a) if the previous lifetimes given the client are still applicable and there is no need for the server to update them (since the client can use those addresses until the valid lifetime expires). I'm sure I missed a few of your questions. Good comments. - Bernie Volz Ericsson -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Monday, March 12, 2001 7:06 PM To: DHCPv6 discussion list Subject: questions on DHCPv6 -18 rev of draft Hi, I have few questions regarding the -18 rev of DHCPv6 draft. I will be attending the design telecon. let me know your comments about these issues. Regrads, Vijay questions --------- * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 implmentation has to take care of the fragmentation. Assume the client has fragmented the packet in to two packets. The server will read the first packet correctly, since it is in proper packet format. Then, the second packet will be discarded, since it has only the remaining content of the previously sent packet. This is because, the server doesn't know that whether the packet recieved is correct one or the later part of the prviously sent fragmented packet. Do we need to have an additional message type (or) a field speciying the "next fragment" for transmission of the fragemented packet? * How DUID is generated? what is its format? * I think we don't need site scoped "All DHCP Clients" multicast address for sending reconfigure messages. Since, renumbering of network takes place per link basis. This means we need to send Reconfigure message to only the nodes in a particular link, not to all the nodes in the site. Thus, if we use All DHCP clients multicast address, most of the nodes will unecessarily receive the Reconfigure-init message. * There are some list of Generic Error values like AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned how to return this error value. We need an option or a field for returning these generic error values. This option must be included in the base-spec. * In solicit message, does the client need to send the number of IP address needed for the IA, in the IA option? I think it is better to send the requested number of IP address in the Ia option. If the client is asking "n" number of IP address and the server can offer only "m" IP-addresses (mThe server MUST include options to Advertise message containing any address >that would be assigned to IAs contained in the Solicit message format. 1. Is this similar to the DHCP OFFER in DHCPv4? 2. If the client has asked "n" IP address, does the server need to send "n" address in the IA? (or) need to send the just the prefix? 3. If the server does not have one or few of the requested configuration parameters asked by the client in ORO option, does the server need to send the only the configuration parameters it have and leave the other options. (or) since it doesn't have some of the configuration parameters, will it tollaly ignore the Solicit and don't send reply? 4. If the server can offer only few IP-address (m) less than the requested number of IP-address (n), does the server needs to respond with the available number of IP-address (OR) doesn't send Advertise? 5. If the server is sending the "n" IP Addresses in IA option in Advertise message, it means that, these addresses should not be assigned to the other clients and is reserved for the client that has sent the Solicit? Request message _______________ 1. assume, the client has asked 2 IP address first time. After some times, it needs another 3 IP-address in the same interface. This time, does it need to send a fresh empty IA? or it can ask for another 3 IP-address in the same IA? a) If it has to send the fresh empty IA, how will the server maintain the record of these IAs, since the IA sent at the first time and sent next time will have the same DUID and subnet-prefix. Will the server treat these two as different or same IAs? b) why empty IA is to be sent for requesting IP address? c) what does exactly the empty IA mean? In other words, what are the fields to be filled in IA options for sending the empty IA. (eg):- If the client is requesting 3 IP-address, I think these are fields which must be filled. (1) option-code (2) option-len (3) IA-DUID (4) num-addrs = 3 do the addr status, prefix length, IPv6 address, pref life time, val life time should be present or filled with zeros? 2. If the client has sufficient scope to reach the server, then why can't it send the Request message directly? Why is it mentioned in the draft that it should send the Request message to All DHCP Agents Address? This situtation holds for renew and rebind message also. Release Message _______________ For sending DHCP Release message, does the client include addresses to be released? (or) includes ONLY the address to be released? Authentication Option _____________________ Why authentication option is to be included as the last option? If it is included as the first option, it will be easier to authenicate first and in case, if authentication fails, it can directly reject the packet without processing further. Sending deprecated address __________________________ Assume 1. A network renumbering for a particular link has occured. The prefix 5ffe:: is changed to 3ffe:: 2. An IA for a node in this link has following addresses, 5ffe::20 and 5ffe::21 3. Now reconfiguration has been triggered and the server has sent the Reconfigure-init message to the client. 4. Client has responded with DHCP Request. a) does the server has to delete the addresses 5ffe::20 and 5ffe::21 from the IA and include 3ffe::20 and 3ffe:21 in the IA? (or) b) for graceful renumbering, it can add new IP-address 3ffe::20 and 3ffe:21 to the IA along with the orginal 5ffe addresses? In this case, i feel that the old prefix addresses (5ffe) should be made deprecated one with the prefered-lifetime = 0 and valid-lifetime = some grace period. I think this is a MUST one for renumbering. _______________________ * In the draft, in one section(12.3.2) , it is mentioned that, client has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In another section( WAIT collecting Advertise message. Since both the variable has different default values, which is to be used? ------_=_NextPart_001_01C0AB56.7E2ADF90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: questions on DHCPv6 -18 rev of draft

Some comments regarding your questions:

Fragmentation - This problem doesn't exist. The IPv6 = layer will reassemble the packet. If the packet is multicast on the = link, the other systems on that link in the destination multicast group = will all reassemble the packet before processing it. So, whether it is = a relay agent or a server doesn't matter. Also, if the relay is = unicasting the packet to a server, same thing happens (it will be = reassembled). This fragmentation is NOT something that the DHCP Client = code does - but something that happens at the IPv6 layer. So, if the = -18 text isn't clear about this, we need to fix it.

DUID - How it is generated is still the $64,000 = question. There have been some proposals in discussions.

All DHCP Clients Multicast - I agree, it should be = link local. This hasn't yet been fully explored. It appears, from the = -18 draft, that the server somehow communicates the client to tell it = what Multicast group to join, but I think that has flaws in it. (I'm in = the process of writing up some review comments as well in preparation = for the conference call and this was one of my issues.)

Solicit message - The client just sends whatever IA = option(s) it would send with a Request. This allows the server to = respond with what it would assign on receipt of the Request. And, yes = this is very similar to the DHCP DISCOVER/OFFER. The reason is that the = client may need this information to make a decision as to which = Advertise it will accept.

Note that the specification (12.3.1) says: "all = of the IAs MUST be empty" (when creating the Solicit).

I believe that the server should reply even if it = can't honor all of the options in the ORO - the client can decide which = to take based on what it receives (if it needs a particular option, it = can discard the ones without it). That's what we do in = DHCPv4.

If the server Advertises addresses, it should behave = similar to DHCPv4's OFFER in that the server SHOULD not reassign these = addresses for a short time to 'reserve' them for the client. But, it is = only a SHOULD and not a MUST (the server may change the addresses in = the REPLY).

Note that when the Client constructs the Request = "The list of addresses in each included IA MUST be empty." = (13.3.1). Therefore, unless the server takes steps to 'reserve' the = addresses, the client should have forgotten about them.

Request message (client wants more addresss) - If a = client wants new addresses, it must use a new IA. This new DUID must be = different than the previous. The DUID really is a client = identifier/interface identifier/address request identifier. I think = this has gotten lost in the draft text.

The reason for sending *ALL* client requests via the = multicast mechanism is such that if a relay agent is between the client = and server IT WILL ALWAYS BE between the client and server. Therefore, = things like the DHCPv4 Relay Agent options can always be inserted in = the clients requests and the server always has complete information. = This is actually a nice solution. There are also others (such as if = there are failover partners, they can respond on behalf of each other = if they know the target server is down). There is of course a cost, but = it is rather low. One option we could consider (though at the lost of = some potential features such as the failover one) is allowing a client = to unicast to the server IF AND ONLY IF the server is on the link (ie, = the server's address is a link-local). For in that case, no relay = options would be added. But, I'm not in favor of this.

Release message - A client can release one or many = addresses (either in one or multiple IAs). It need not release all of = the addresses in a single IA.

Sending deprecated address - I would expect that the = server to do (b) - include both the old addresses (with lifetimes = adjusted) and the new. However, it may also do (a) if the previous = lifetimes given the client are still applicable and there is no need = for the server to update them (since the client can use those addresses = until the valid lifetime expires).


I'm sure I missed a few of your questions. Good = comments.

- Bernie Volz
  Ericsson

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Monday, March 12, 2001 7:06 PM
To: DHCPv6 discussion list
Subject: questions on DHCPv6 -18 rev of draft


Hi,
I have few questions regarding the -18 rev of DHCPv6 = draft. I will be
attending the design telecon. let me know your = comments about these
issues.
Regrads,
Vijay

questions
---------

* Since, in IPv6 routers won't handle the = fragmentation. so, DHCPv6
implmentation has to take care of the fragmentation. =
Assume the client has fragmented the packet in to = two packets. The
server will
read the first packet correctly, since it is in = proper packet format.
Then, the second packet will be discarded, since it = has only the
remaining
content of the previously sent packet.
This is because, the server doesn't know that = whether the packet
recieved is
correct one or the later part of the  prviously = sent fragmented packet.
Do we need to have an additional message type (or) a = field speciying the
"next fragment" for transmission of the = fragemented packet?

* How DUID is generated? what is its format?

* I think we don't need site scoped "All DHCP = Clients" multicast address
for sending reconfigure messages. Since, renumbering = of network takes
place per link basis. This means we need to send = Reconfigure message to
only the nodes in a particular link, not to all the = nodes in the site.
Thus, if we use All DHCP clients multicast address, = most of the nodes
will unecessarily receive the Reconfigure-init  = message.

* There are some list of Generic Error values = like
AuthFailed,PoorlyFormed etc. are defined. But no = where it is mentioned
how to return this error value. We need an option or = a field for
returning these generic error values. This option = must be included in
the base-spec.


* In solicit message, does the client need to send = the number of IP
address needed for the IA, in the IA option? I think = it is better to
send the requested number of IP address in the Ia = option. If the client
is asking "n" number of IP address and the = server can offer only "m"
IP-addresses (m<n), then the client can choose = better server offering
"n" IP address. This can become one = criteria for selecting the server to
send the DHCP Request message.

>The server MUST include options to Advertise = message containing any address >that would be assigned to IAs = contained in the Solicit message format.

1. Is this similar to the DHCP OFFER in = DHCPv4?
2. If the client has asked "n" IP address, = does the server need to send
"n" address in the IA? (or) need to send = the just the prefix?
3. If the server does not have one or few of the = requested configuration
parameters asked by the client in ORO option, does = the server need to
send the only the configuration parameters it have = and leave the other
options. (or) since it doesn't have some of the = configuration
parameters, will it tollaly ignore the Solicit and = don't send reply?
4. If the server can offer only few IP-address (m) = less than the
requested number of IP-address (n), does the server = needs to respond
with the available number of IP-address (OR) doesn't = send Advertise?
5. If the server is sending the "n" IP = Addresses in IA option in
Advertise message, it means that, these addresses = should not be assigned
to the other clients and is reserved for the client = that has sent the
Solicit?


Request message
_______________

1. assume, the client has asked 2 IP address first = time. After some
times, it needs another 3 IP-address in the same = interface. This time,
does it need to send a fresh empty IA? or it can ask = for another 3
IP-address in the same IA?

a) If it has to send the fresh empty IA, how will the = server maintain
the record of these IAs, since the IA sent at the = first time and sent
next time will have the same DUID and subnet-prefix. = Will the server
treat these two as different or same IAs?

b) why empty IA is to be sent for requesting IP = address?

c) what does exactly the empty IA mean? In other = words, what are the
fields to be filled in IA options for sending the = empty IA.

(eg):- If the client is requesting 3 = IP-address,
I think these are fields which must be = filled.
(1) option-code
(2) option-len
(3) IA-DUID
(4) num-addrs =3D 3

do the addr status, prefix length, IPv6 address, pref = life time, val
life time should be present or filled with = zeros?

2. If the client has sufficient scope to reach the = server, then why
can't it send the Request message directly? Why is = it mentioned in the
draft that it should send the Request message to All = DHCP Agents
Address? This situtation holds for renew and rebind = message also.

Release Message
_______________

For sending DHCP Release message, does the client = include addresses to
be released? (or) includes ONLY the address to be = released?

Authentication Option
_____________________

Why authentication option is to be included as the = last option?
If it is included as the first option, it will be = easier to authenicate
first and in case, if authentication fails, it can = directly reject the
packet without processing further.

Sending deprecated address
__________________________

Assume
1. A network renumbering for a particular link has = occured. The prefix
5ffe:: is changed to 3ffe::  
2. An IA for a node in this link has following = addresses, 5ffe::20 and
5ffe::21
3. Now reconfiguration has been triggered and the = server has sent the
Reconfigure-init message to the client.
4. Client has responded with DHCP Request.

a) does the server has to delete the addresses = 5ffe::20 and 5ffe::21
from the IA and include 3ffe::20 and 3ffe:21 in the = IA?
(or)
b) for graceful renumbering, it can add new = IP-address 3ffe::20 and
3ffe:21 to the IA along with the orginal 5ffe = addresses?
In this case, i feel that the old prefix addresses = (5ffe) should be made
deprecated one with the prefered-lifetime =3D 0 and = valid-lifetime =3D some
grace period. I think this is a MUST one for = renumbering.

_______________________

* In the draft, in one section(12.3.2) , it is = mentioned that, client
has to wait for ADV_MSG_TIMEOUT collecting the = Advertise messages. In
another section( WAIT collecting Advertise message. = Since both the
variable has different default values, which is to = be used?

------_=_NextPart_001_01C0AB56.7E2ADF90-- From owner-dhcp-v6@bucknell.edu Mon Mar 12 22:49:14 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00159; Mon, 12 Mar 2001 22:49:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2D3kTL04966; Mon, 12 Mar 2001 22:46:29 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2D3kNL26952 for ; Mon, 12 Mar 2001 22:46:23 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2D3mAw21361 for ; Mon, 12 Mar 2001 21:48:10 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 12 Mar 2001 21:46:20 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 12 Mar 2001 21:46:20 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: questions on DHCPv6 -18 rev of draft Date: Mon, 12 Mar 2001 21:46:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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, > questions > --------- > > * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 > implmentation has to take care of the fragmentation. > Assume the client has fragmented the packet in to two packets. The > server will > read the first packet correctly, since it is in proper packet format. > Then, the second packet will be discarded, since it has only the > remaining > content of the previously sent packet. > This is because, the server doesn't know that whether the packet > recieved is > correct one or the later part of the prviously sent > fragmented packet. > Do we need to have an additional message type (or) a field > speciying the > "next fragment" for transmission of the fragemented packet? IPv6 fragmentation is now end-to-end. The DHCPv6 server is an IPv6 capable node. Hence, it MUST be able to reassemble IPv6 packets with Hdr Ext of Fragment Header. > > * How DUID is generated? what is its format? Ted Mellon had an algorithm Ralph and I feel had "rough" consensus our hope is Ted will write this up for us for last call. But it is missing now yes. > > * I think we don't need site scoped "All DHCP Clients" > multicast address > for sending reconfigure messages. Since, renumbering of network takes > place per link basis. This means we need to send Reconfigure > message to > only the nodes in a particular link, not to all the nodes in the site. > Thus, if we use All DHCP clients multicast address, most of the nodes > will unecessarily receive the Reconfigure-init message. If a server is multisited this will be useful. So I think we need to keep this multicast address. Clearly we may need other ones and we should document that. > > * There are some list of Generic Error values like > AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned > how to return this error value. We need an option or a field for > returning these generic error values. This option must be included in > the base-spec. Both of these came out of when we had DNS support in dhcpv6. We should review each error condition and if it is not referenced it should be removed. Also we should see if we are missing any. Ralph and I found several new ones we needed in draft 17 for those watching this. We need to get these right for last call. If you have ideas of where we might use new ones or existing ones it would be very cool if you tell us too. Thanks..... > > > * In solicit message, does the client need to send the number of IP > address needed for the IA, in the IA option? I think it is better to > send the requested number of IP address in the Ia option. If > the client > is asking "n" number of IP address and the server can offer only "m" > IP-addresses (m "n" IP address. This can become one criteria for selecting > the server to > send the DHCP Request message. In draft 18 that is implied. In 12.3.1 The client MUST include options for any IAs to which the client is expecting to have the server assign addresses. Because the client does not have any IAs with addresses when sending a Solicit message, all of the IAs MUST be empty. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. > > >The server MUST include options to Advertise message > containing any address >that would be assigned to IAs > contained in the Solicit message format. > > 1. Is this similar to the DHCP OFFER in DHCPv4? Yes. > 2. If the client has asked "n" IP address, does the server > need to send > "n" address in the IA? (or) need to send the just the prefix? No. The server can respond with no options too. Or just the addresses it wants to give. > 3. If the server does not have one or few of the requested > configuration > parameters asked by the client in ORO option, does the server need to > send the only the configuration parameters it have and leave the other > options. (or) since it doesn't have some of the configuration > parameters, will it tollaly ignore the Solicit and don't send reply? The server only sends an advertise to a solicit. Not a reply. Do you want to reread the advertise server section again? But the server is free to send something or nothing as options in advertise. > 4. If the server can offer only few IP-address (m) less than the > requested number of IP-address (n), does the server needs to respond > with the available number of IP-address (OR) doesn't send Advertise? In advertise there is not mandate for response other than the header msg but servers who do with equal preference level will most likely get used by the client. We did write this all down? > 5. If the server is sending the "n" IP Addresses in IA option in > Advertise message, it means that, these addresses should not > be assigned > to the other clients and is reserved for the client that has sent the > Solicit? That is what a smart server should do. A dumb one won't. :-----) We can probably add a server should keep the addresses for x time. > > > Request message > _______________ > > 1. assume, the client has asked 2 IP address first time. After some > times, it needs another 3 IP-address in the same interface. This time, > does it need to send a fresh empty IA? or it can ask for another 3 > IP-address in the same IA? We should bring this up on the design conference call. We don't say now. We had long discussions on this mailing list about not permitting clients to do this. But we do permit clients to request a number of addresses in the Request. If we permit this I would suggest it can be done at Renew. But this needs to be discussed. > > a) If it has to send the fresh empty IA, how will the server maintain > the record of these IAs, since the IA sent at the first time and sent > next time will have the same DUID and subnet-prefix. Will the server > treat these two as different or same IAs? Good question. The IA DUID identifies the address set for a client. Right now should there be any duplicates the prefix avoids that as the prefix in IPv6 cannot be duplicated AS LONG AS ITS a GLOBAL PREFIX if the server is multisited. So there is a one-to-one relationship btw the clients addresses and a DUID and prefix today. If the server gets another IA from the same client right now in the spec there is no way to differentiate that they are connected to the same client at all. See my next mail to Bernie on his question. Ralph and I caught this in the spec and were going to bring it up under DUID and Prefix. But see my next mail to Bernie on him asking about client identification. > > b) why empty IA is to be sent for requesting IP address? A Request message is for the first time the client requests addresses. See Confirm, Renew, and Rebind text. > > c) what does exactly the empty IA mean? In other words, what are the > fields to be filled in IA options for sending the empty IA. We force you right now to fill in num-addrs and zero filled address for each one. The reason is that working group consensus was that there is benefit in constant IA set of fields. We could discuss just sending upto prefix length? > > (eg):- If the client is requesting 3 IP-address, > I think these are fields which must be filled. > (1) option-code > (2) option-len > (3) IA-DUID > (4) num-addrs = 3 I agree but this means altering how much of the option we send. We can discuss I think lets bring it up. You should send specific wording for topics you want to discuss on the design con call is my suggestion. That way it is easier for Ralph to record in separate mail thread or send to Ralph privately and cc me if you like. > > do the addr status, prefix length, IPv6 address, pref life time, val > life time should be present or filled with zeros? This is an omission. Yes. Unless we don't send them. > > 2. If the client has sufficient scope to reach the server, then why > can't it send the Request message directly? Why is it mentioned in the > draft that it should send the Request message to All DHCP Agents > Address? This situtation holds for renew and rebind message also. Good catch. That should only apply to the Request. In fact by definition only the server that provided the addresess can Confirm or Renew. So those should be sent directly to them. On Rebind the client can remember other servers and send to them directly or use Multicast. For Request the idea was to permit the client to avoid having to recall the relays address if when it still does not have a routable ip address. We should clarify on design call. > > Release Message > _______________ > > For sending DHCP Release message, does the client include addresses to > be released? (or) includes ONLY the address to be released? The client must include ONLY the addresses to be released. > > Authentication Option > _____________________ > > Why authentication option is to be included as the last option? > If it is included as the first option, it will be easier to > authenicate > first and in case, if authentication fails, it can directly reject the > packet without processing further. I will let Ralph answer this. This is TBD we ran out of time for this draft. > > Sending deprecated address > __________________________ > > Assume > 1. A network renumbering for a particular link has occured. The prefix > 5ffe:: is changed to 3ffe:: > 2. An IA for a node in this link has following addresses, 5ffe::20 and > 5ffe::21 > 3. Now reconfiguration has been triggered and the server has sent the > Reconfigure-init message to the client. > 4. Client has responded with DHCP Request. > > a) does the server has to delete the addresses 5ffe::20 and 5ffe::21 > from the IA and include 3ffe::20 and 3ffe:21 in the IA? Not if the valid life time has not expired. > (or) > b) for graceful renumbering, it can add new IP-address 3ffe::20 and > 3ffe:21 to the IA along with the orginal 5ffe addresses? > In this case, i feel that the old prefix addresses (5ffe) > should be made > deprecated one with the prefered-lifetime = 0 and > valid-lifetime = some > grace period. I think this is a MUST one for renumbering. I believe this is a good policy and a good idea. But I do not think we can mandate how that is done in the spec. We could have an appendix like this though? > > _______________________ > > * In the draft, in one section(12.3.2) , it is mentioned that, client > has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In > another section( WAIT collecting Advertise message. Since both the > variable has different default values, which is to be used? Sounds like we have a typo problem but I could not find the other missing WAIT? Can you send to me privately. thanks for the thorough review, /jim > From owner-dhcp-v6@bucknell.edu Tue Mar 13 03:50:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17472; Tue, 13 Mar 2001 03:50:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2D8llL27798; Tue, 13 Mar 2001 03:47:47 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2D8lbL25657 for ; Tue, 13 Mar 2001 03:47:38 -0500 (EST) Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA315508 for ; Tue, 13 Mar 2001 19:37:53 +1100 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m3/NCO v4.95) with SMTP id TAA77978 for ; Tue, 13 Mar 2001 19:45:23 +1100 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A0E.003015B8 ; Tue, 13 Mar 2001 19:45:12 +1100 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Tue, 13 Mar 2001 11:38:43 +0530 Subject: Server Preference Value in DHCPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 have a few doubts regarding the "preference" field. I would like to know the importance of server preference value from the client perspective. In draft 17 it is mentioned that the setting of a server preference value SHOULD be allowed by administrator. What decides a server to be of "high prefernce" and how does an administrator selects a value. Does it depend upon the number of addresses that a server can give (or) the link/relay through which the server receive the SOLICIT messages (or) the efficiency of the machine ( ???? ) (or) just an administrators option which is constant throughout. thanks and regards Suresh Kodati IBM India Software Labs Email:- skodati@in.ibm.com From owner-dhcp-v4@bucknell.edu Tue Mar 13 05:50:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18020 for ; Tue, 13 Mar 2001 05:50:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DAhvL03621; Tue, 13 Mar 2001 05:43:57 -0500 (EST) Received: from tsmtp4.mail.isp (mailhost.terra.es [195.235.113.151] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DAhoL22525 for ; Tue, 13 Mar 2001 05:43:51 -0500 (EST) Received: from teleline.es ([10.10.21.70]) by tsmtp4.mail.isp (Netscape Messaging Server 4.15) with ESMTP id GA4TO706.USG for ; Tue, 13 Mar 2001 11:40:55 +0100 From: JTACULOJ To: DHCPv4 discussion list Message-ID: <5f4035f506.5f5065f403@teleline.es> Date: Tue, 13 Mar 2001 11:40:55 +0100 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: more than one dhcp server on th same machine X-Accept-Language: es Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f2DAhpL15172 Reply-To: JTACULOJ@terra.es Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-MIME-Autoconverted: from 8bit to quoted-printable by mail.bucknell.edu id f2DAhvL03621 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA18020 Hi all, I have the following configuration. we have more than 8 remote networks, each of then with their own C classs address range. Every network is connected throught a cisco router that uses ip helpper-address to ask for ip address to a dhcp server. Questions: 1) Can i have a single dhcp server that manage connections from clients and give them an IP of their range depending on source Router IP. 2) If I have two networks attached to the same router how can i give clients a ip of their range ( different DHCP server?, one for each ) 3) If i do, so can I have two or more DHCP instances on the same server (with different IP address (aliases), and different configuration Files on the same Machine). 4) Is this possible in a Linux Enviroment Any help would be apreciated, i think we are on trouble Thanks Jorge Cuesta López ___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES Haz clic en http://www.terra.es/correo/ From owner-dhcp-v6@bucknell.edu Tue Mar 13 08:48:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19769; Tue, 13 Mar 2001 08:48:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DDjPL29905; Tue, 13 Mar 2001 08:45:26 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DDjML07871 for ; Tue, 13 Mar 2001 08:45:22 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2DDjNg16643 for ; Tue, 13 Mar 2001 07:45:23 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 Mar 2001 07:45:21 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Mar 2001 07:45:21 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Server Preference Value in DHCPv6 Date: Tue, 13 Mar 2001 07:45:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 thats really up to the customer isn't it. we give them the tool to define whats important to their network. /jim > -----Original Message----- > From: ext skodati@in.ibm.com [mailto:skodati@in.ibm.com] > Sent: Tuesday,March 13,2001 1:09 AM > To: DHCPv6 discussion list > Subject: Server Preference Value in DHCPv6 > > > > I have a few doubts regarding the "preference" field. I > would like to know > the importance of server preference value from the client perspective. > > In draft 17 it is mentioned that the setting of a server > preference value > SHOULD be allowed by administrator. What decides a server to > be of "high > prefernce" and how does an administrator selects a value. > Does it depend upon > the number of addresses that a server can give > (or) the link/relay through which the server receive the SOLICIT > messages > (or) the efficiency of the machine ( ???? ) > (or) just an administrators option which is constant throughout. > > thanks and regards > Suresh Kodati > IBM India Software Labs > Email:- skodati@in.ibm.com > From owner-dhcp-v6@bucknell.edu Tue Mar 13 09:23:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20681; Tue, 13 Mar 2001 09:23:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DEKwL16489; Tue, 13 Mar 2001 09:20:58 -0500 (EST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DEKkL13237 for ; Tue, 13 Mar 2001 09:20:46 -0500 (EST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2DEKUd38143 for ; Tue, 13 Mar 2001 15:20:30 +0100 Received: from rennes.enst-bretagne.fr (gaia.ipv6.rennes.enst-bretagne.fr [192.108.119.164]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA13505 for ; Tue, 13 Mar 2001 15:20:29 +0100 (MET) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3AAE2C99.9B9F3C14@rennes.enst-bretagne.fr> Date: Tue, 13 Mar 2001 15:20:09 +0100 From: Jerome MARCHAND X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: options in DHCP SOLICIT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: marchand@rennes.enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit In section 12.3.1 of draft 18, I see that we are supposed to send an IA option in the dhcp SOLICIT message. What information does it provide to the server ? When the server reply, what are the modifications applied to the IA option ? And what information does it provide to the client ? Thanks and regards ********************** Jerome MARCHAND ENST RENNES, FRANCE ********************** From owner-dhcp-v6@bucknell.edu Tue Mar 13 09:40:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21035; Tue, 13 Mar 2001 09:40:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DEdwL23469; Tue, 13 Mar 2001 09:39:58 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DEdhL24636 for ; Tue, 13 Mar 2001 09:39:43 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2DEfXw07603 for ; Tue, 13 Mar 2001 08:41:33 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 Mar 2001 08:39:42 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Mar 2001 08:39:42 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: options in DHCP SOLICIT Date: Tue, 13 Mar 2001 08:39:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 > -----Original Message----- > From: ext Jerome MARCHAND > [mailto:jerome.marchand@rennes.enst-bretagne.fr] > Sent: Tuesday,March 13,2001 9:20 AM > To: DHCPv6 discussion list > Subject: options in DHCP SOLICIT > > > In section 12.3.1 of draft 18, I see that we are supposed to > send an IA > option > in the dhcp SOLICIT message. What information does it provide to the > server ? It is not mandatory the client can provide empty IAs and OROs. > When the server reply, what are the modifications applied to the IA > option ? Its a server "Advertise" not "Reply" the server may respond to the options and fill in the IAs. > And what information does it provide to the client ? See above. /jim > From owner-dhcp-v6@bucknell.edu Tue Mar 13 10:25:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21827; Tue, 13 Mar 2001 10:25:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DFLYL09280; Tue, 13 Mar 2001 10:21:34 -0500 (EST) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DFLIL25859 for ; Tue, 13 Mar 2001 10:21:18 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel2.hp.com (Postfix) with ESMTP id D778B59 for ; Tue, 13 Mar 2001 10:21:13 -0500 (EST) Received: from india.hp.com (vijayak@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 UAA01589 for ; Tue, 13 Mar 2001 20:49:00 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3AAE3B67.90E4BE8@india.hp.com> Date: Tue, 13 Mar 2001 20:53:19 +0530 From: Vijay Bhaskar A K Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: questions on DHCPv6 -18 rev of draft References: <66F66129A77AD411B76200508B65AC691F6582@eambunt705.ena-east.ericsson.se> 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 > "Bernie Volz (EUD)" wrote: > > Some comments regarding your questions: > > Fragmentation - This problem doesn't exist. The IPv6 layer will > reassemble the packet. If the packet is multicast on the link, the > other systems on that link in the destination multicast group will all > reassemble the packet before processing it. So, whether it is a relay > agent or a server doesn't matter. Also, if the relay is unicasting the > packet to a server, same thing happens (it will be reassembled). This > fragmentation is NOT something that the DHCP Client code does - but > something that happens at the IPv6 layer. So, if the -18 text isn't > clear about this, we need to fix it. Yes. I think the draft has to make clear this. > > DUID - How it is generated is still the $64,000 question. There have > been some proposals in discussions. > > All DHCP Clients Multicast - I agree, it should be link local. This > hasn't yet been fully explored. It appears, from the -18 draft, that > the server somehow communicates the client to tell it what Multicast > group to join, but I think that has flaws in it. (I'm in the process > of writing up some review comments as well in preparation for the > conference call and this was one of my issues.) > I feel that having All DHCP Clients Multicast address will be only an additional overhead. Consider the following situation. 1. Consider a site with links m,n,o,p. "p" has been renumbered. 2. The server will send the reconfigure-init message to the All DHCP Client Site local multicast address. Since this is an site-scoped address, all the clients in links m,n,o,p will respond with DHCP Request, flooding the network. But, the server actually wanted the clients in link "p" to respond. If we define All DHCP Client Multicast address as a link-local one, then, how wiil the server sends the reconfigure-init message to the clients in the links which are not directly connected to the server. I feel that, instead of defining a multicast address for this purpose, if a range of multicast address of site-local scope is specified, then the server can allocate one Reconfigure multicast address for one group. (nodes belonging to one/two links can form a group). Thus, it prevents other applications from using these multicast addresses. In the draft it is said that, Reconfigure-int MAY contain ORO option. In case, if it is not there, what are the options that the client has to send in the Request message? I feel that Reconfigure-init MUST contain ORO option to specify the client the options/parameters that has been changed. Then only, the client can request for those options. > Solicit message - The client just sends whatever IA option(s) it would > send with a Request. This allows the server to respond with what it > would assign on receipt of the Request. And, yes this is very similar > to the DHCP DISCOVER/OFFER. The reason is that the client may need > this information to make a decision as to which Advertise it will > accept. > > Note that the specification (12.3.1) says: "all of the IAs MUST be > empty" (when creating the Solicit). > > I believe that the server should reply even if it can't honor all of > the options in the ORO - the client can decide which to take based on > what it receives (if it needs a particular option, it can discard the > ones without it). That's what we do in DHCPv4. > > If the server Advertises addresses, it should behave similar to > DHCPv4's OFFER in that the server SHOULD not reassign these addresses > for a short time to 'reserve' them for the client. But, it is only a > SHOULD and not a MUST (the server may change the addresses in the > REPLY). The short time that the server 'reserve' the addresses needs to be defined. > > Note that when the Client constructs the Request "The list of > addresses in each included IA MUST be empty." (13.3.1). Therefore, > unless the server takes steps to 'reserve' the addresses, the client > should have forgotten about them. > > Request message (client wants more addresss) - If a client wants new > addresses, it must use a new IA. This new DUID must be different than > the previous. The DUID really is a client identifier/interface > identifier/address request identifier. I think this has gotten lost in > the draft text. Why do we need the seperate IA for the getting new addresses. Is there any specific reason for not sending the request for new addresses in the same IA? > > The reason for sending *ALL* client requests via the multicast > mechanism is such that if a relay agent is between the client and > server IT WILL ALWAYS BE between the client and server. Therefore, > things like the DHCPv4 Relay Agent options can always be inserted in > the clients requests and the server always has complete information. > This is actually a nice solution. There are also others (such as if > there are failover partners, they can respond on behalf of each other > if they know the target server is down). There is of course a cost, > but it is rather low. One option we could consider (though at the lost > of some potential features such as the failover one) is allowing a > client to unicast to the server IF AND ONLY IF the server is on the > link (ie, the server's address is a link-local). For in that case, no > relay options would be added. But, I'm not in favor of this. yes. this is ok. It will be better to use multicast instead of unicast. > > Release message - A client can release one or many addresses (either > in one or multiple IAs). It need not release all of the addresses in a > single IA. > > Sending deprecated address - I would expect that the server to do (b) > - include both the old addresses (with lifetimes adjusted) and the > new. However, it may also do (a) if the previous lifetimes given the > client are still applicable and there is no need for the server to > update them (since the client can use those addresses until the valid > lifetime expires). thanks for clarifying the doubts. Vijay. > > I'm sure I missed a few of your questions. Good comments. > > - Bernie Volz > Ericsson > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Monday, March 12, 2001 7:06 PM > To: DHCPv6 discussion list > Subject: questions on DHCPv6 -18 rev of draft > > Hi, > I have few questions regarding the -18 rev of DHCPv6 draft. I will be > attending the design telecon. let me know your comments about these > issues. > Regrads, > Vijay > > questions > --------- > > * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 > implmentation has to take care of the fragmentation. > Assume the client has fragmented the packet in to two packets. The > server will > read the first packet correctly, since it is in proper packet format. > Then, the second packet will be discarded, since it has only the > remaining > content of the previously sent packet. > This is because, the server doesn't know that whether the packet > recieved is > correct one or the later part of the prviously sent fragmented > packet. > Do we need to have an additional message type (or) a field speciying > the > "next fragment" for transmission of the fragemented packet? > > * How DUID is generated? what is its format? > > * I think we don't need site scoped "All DHCP Clients" multicast > address > for sending reconfigure messages. Since, renumbering of network takes > place per link basis. This means we need to send Reconfigure message > to > only the nodes in a particular link, not to all the nodes in the site. > > Thus, if we use All DHCP clients multicast address, most of the nodes > will unecessarily receive the Reconfigure-init message. > > * There are some list of Generic Error values like > AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned > > how to return this error value. We need an option or a field for > returning these generic error values. This option must be included in > the base-spec. > > * In solicit message, does the client need to send the number of IP > address needed for the IA, in the IA option? I think it is better to > send the requested number of IP address in the Ia option. If the > client > is asking "n" number of IP address and the server can offer only "m" > IP-addresses (m "n" IP address. This can become one criteria for selecting the server > to > send the DHCP Request message. > > >The server MUST include options to Advertise message containing any > address >that would be assigned to IAs contained in the Solicit > message format. > > 1. Is this similar to the DHCP OFFER in DHCPv4? > 2. If the client has asked "n" IP address, does the server need to > send > "n" address in the IA? (or) need to send the just the prefix? > 3. If the server does not have one or few of the requested > configuration > parameters asked by the client in ORO option, does the server need to > send the only the configuration parameters it have and leave the other > > options. (or) since it doesn't have some of the configuration > parameters, will it tollaly ignore the Solicit and don't send reply? > 4. If the server can offer only few IP-address (m) less than the > requested number of IP-address (n), does the server needs to respond > with the available number of IP-address (OR) doesn't send Advertise? > 5. If the server is sending the "n" IP Addresses in IA option in > Advertise message, it means that, these addresses should not be > assigned > to the other clients and is reserved for the client that has sent the > Solicit? > > Request message > _______________ > > 1. assume, the client has asked 2 IP address first time. After some > times, it needs another 3 IP-address in the same interface. This time, > > does it need to send a fresh empty IA? or it can ask for another 3 > IP-address in the same IA? > > a) If it has to send the fresh empty IA, how will the server maintain > the record of these IAs, since the IA sent at the first time and sent > next time will have the same DUID and subnet-prefix. Will the server > treat these two as different or same IAs? > > b) why empty IA is to be sent for requesting IP address? > > c) what does exactly the empty IA mean? In other words, what are the > fields to be filled in IA options for sending the empty IA. > > (eg):- If the client is requesting 3 IP-address, > I think these are fields which must be filled. > (1) option-code > (2) option-len > (3) IA-DUID > (4) num-addrs = 3 > > do the addr status, prefix length, IPv6 address, pref life time, val > life time should be present or filled with zeros? > > 2. If the client has sufficient scope to reach the server, then why > can't it send the Request message directly? Why is it mentioned in the > > draft that it should send the Request message to All DHCP Agents > Address? This situtation holds for renew and rebind message also. > > Release Message > _______________ > > For sending DHCP Release message, does the client include addresses to > > be released? (or) includes ONLY the address to be released? > > Authentication Option > _____________________ > > Why authentication option is to be included as the last option? > If it is included as the first option, it will be easier to > authenicate > first and in case, if authentication fails, it can directly reject the > > packet without processing further. > > Sending deprecated address > __________________________ > > Assume > 1. A network renumbering for a particular link has occured. The prefix > > 5ffe:: is changed to 3ffe:: > 2. An IA for a node in this link has following addresses, 5ffe::20 and > > 5ffe::21 > 3. Now reconfiguration has been triggered and the server has sent the > Reconfigure-init message to the client. > 4. Client has responded with DHCP Request. > > a) does the server has to delete the addresses 5ffe::20 and 5ffe::21 > from the IA and include 3ffe::20 and 3ffe:21 in the IA? > (or) > b) for graceful renumbering, it can add new IP-address 3ffe::20 and > 3ffe:21 to the IA along with the orginal 5ffe addresses? > In this case, i feel that the old prefix addresses (5ffe) should be > made > deprecated one with the prefered-lifetime = 0 and valid-lifetime = > some > grace period. I think this is a MUST one for renumbering. > > _______________________ > > * In the draft, in one section(12.3.2) , it is mentioned that, client > has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In > another section( WAIT collecting Advertise message. Since both the > variable has different default values, which is to be used? From owner-dhcp-v6@bucknell.edu Tue Mar 13 12:23:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24244; Tue, 13 Mar 2001 12:23:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DHJqL27246; Tue, 13 Mar 2001 12:19:53 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DHJdL04798 for ; Tue, 13 Mar 2001 12:19:39 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2DHBbi26334 for ; Tue, 13 Mar 2001 11:11:38 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2DHBbX27178 for ; Tue, 13 Mar 2001 11:11:37 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Mar 13 11:13:16 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 11:13:15 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F6593@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: questions on DHCPv6 -18 rev of draft Date: Tue, 13 Mar 2001 11:13:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABE0.E3039260" 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 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_001_01C0ABE0.E3039260 Content-Type: text/plain; charset="iso-8859-1" See comments below (BV>). -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, March 13, 2001 10:23 AM To: DHCPv6 discussion list Subject: Re: questions on DHCPv6 -18 rev of draft > "Bernie Volz (EUD)" wrote: > > Some comments regarding your questions: > > Fragmentation - This problem doesn't exist. The IPv6 layer will > reassemble the packet. If the packet is multicast on the link, the > other systems on that link in the destination multicast group will all > reassemble the packet before processing it. So, whether it is a relay > agent or a server doesn't matter. Also, if the relay is unicasting the > packet to a server, same thing happens (it will be reassembled). This > fragmentation is NOT something that the DHCP Client code does - but > something that happens at the IPv6 layer. So, if the -18 text isn't > clear about this, we need to fix it. Yes. I think the draft has to make clear this. > > DUID - How it is generated is still the $64,000 question. There have > been some proposals in discussions. > > All DHCP Clients Multicast - I agree, it should be link local. This > hasn't yet been fully explored. It appears, from the -18 draft, that > the server somehow communicates the client to tell it what Multicast > group to join, but I think that has flaws in it. (I'm in the process > of writing up some review comments as well in preparation for the > conference call and this was one of my issues.) > I feel that having All DHCP Clients Multicast address will be only an additional overhead. Consider the following situation. 1. Consider a site with links m,n,o,p. "p" has been renumbered. 2. The server will send the reconfigure-init message to the All DHCP Client Site local multicast address. Since this is an site-scoped address, all the clients in links m,n,o,p will respond with DHCP Request, flooding the network. But, the server actually wanted the clients in link "p" to respond. If we define All DHCP Client Multicast address as a link-local one, then, how wiil the server sends the reconfigure-init message to the clients in the links which are not directly connected to the server. BV> The DHCP Server needs to communicate through the relays. The DHCP Server BV> must either be preconfigured with a list of the relays or could learn BV> the relays (though that isn't as good if a server is starting cold as BV> it can't trigger reconfigurations until it has learned of the relays). I feel that, instead of defining a multicast address for this purpose, if a range of multicast address of site-local scope is specified, then the server can allocate one Reconfigure multicast address for one group. (nodes belonging to one/two links can form a group). Thus, it prevents other applications from using these multicast addresses. In the draft it is said that, Reconfigure-int MAY contain ORO option. In case, if it is not there, what are the options that the client has to send in the Request message? I feel that Reconfigure-init MUST contain ORO option to specify the client the options/parameters that has been changed. Then only, the client can request for those options. BV> I think the client should always send a full Request regardless of BV> what the ORO options are in the Reconfigure-Init. That way, it can be BV> sure to get complete information. > Solicit message - The client just sends whatever IA option(s) it would > send with a Request. This allows the server to respond with what it > would assign on receipt of the Request. And, yes this is very similar > to the DHCP DISCOVER/OFFER. The reason is that the client may need > this information to make a decision as to which Advertise it will > accept. > > Note that the specification (12.3.1) says: "all of the IAs MUST be > empty" (when creating the Solicit). > > I believe that the server should reply even if it can't honor all of > the options in the ORO - the client can decide which to take based on > what it receives (if it needs a particular option, it can discard the > ones without it). That's what we do in DHCPv4. > > If the server Advertises addresses, it should behave similar to > DHCPv4's OFFER in that the server SHOULD not reassign these addresses > for a short time to 'reserve' them for the client. But, it is only a > SHOULD and not a MUST (the server may change the addresses in the > REPLY). The short time that the server 'reserve' the addresses needs to be defined. BV> Perhaps a default can be provided (I don't recall the DHCPv4 specification BV> having this value). But I think it can also be left to the implementor (or BV> as a configuration parameter on the server. This partially depends on how BV> short you are on addresses (and with IPv6 that isn't likely to be an issue). > > Note that when the Client constructs the Request "The list of > addresses in each included IA MUST be empty." (13.3.1). Therefore, > unless the server takes steps to 'reserve' the addresses, the client > should have forgotten about them. > > Request message (client wants more addresss) - If a client wants new > addresses, it must use a new IA. This new DUID must be different than > the previous. The DUID really is a client identifier/interface > identifier/address request identifier. I think this has gotten lost in > the draft text. Why do we need the seperate IA for the getting new addresses. Is there any specific reason for not sending the request for new addresses in the same IA? BV> How does the server know the client wants more addresses? The num-addr BV> field is supposed to reflect the number of addresses that follow (not BV> the number that is requested) from my understanding. > > The reason for sending *ALL* client requests via the multicast > mechanism is such that if a relay agent is between the client and > server IT WILL ALWAYS BE between the client and server. Therefore, > things like the DHCPv4 Relay Agent options can always be inserted in > the clients requests and the server always has complete information. > This is actually a nice solution. There are also others (such as if > there are failover partners, they can respond on behalf of each other > if they know the target server is down). There is of course a cost, > but it is rather low. One option we could consider (though at the lost > of some potential features such as the failover one) is allowing a > client to unicast to the server IF AND ONLY IF the server is on the > link (ie, the server's address is a link-local). For in that case, no > relay options would be added. But, I'm not in favor of this. yes. this is ok. It will be better to use multicast instead of unicast. > > Release message - A client can release one or many addresses (either > in one or multiple IAs). It need not release all of the addresses in a > single IA. > > Sending deprecated address - I would expect that the server to do (b) > - include both the old addresses (with lifetimes adjusted) and the > new. However, it may also do (a) if the previous lifetimes given the > client are still applicable and there is no need for the server to > update them (since the client can use those addresses until the valid > lifetime expires). thanks for clarifying the doubts. Vijay. > > I'm sure I missed a few of your questions. Good comments. > > - Bernie Volz > Ericsson > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Monday, March 12, 2001 7:06 PM > To: DHCPv6 discussion list > Subject: questions on DHCPv6 -18 rev of draft > > Hi, > I have few questions regarding the -18 rev of DHCPv6 draft. I will be > attending the design telecon. let me know your comments about these > issues. > Regrads, > Vijay > > questions > --------- > > * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 > implmentation has to take care of the fragmentation. > Assume the client has fragmented the packet in to two packets. The > server will > read the first packet correctly, since it is in proper packet format. > Then, the second packet will be discarded, since it has only the > remaining > content of the previously sent packet. > This is because, the server doesn't know that whether the packet > recieved is > correct one or the later part of the prviously sent fragmented > packet. > Do we need to have an additional message type (or) a field speciying > the > "next fragment" for transmission of the fragemented packet? > > * How DUID is generated? what is its format? > > * I think we don't need site scoped "All DHCP Clients" multicast > address > for sending reconfigure messages. Since, renumbering of network takes > place per link basis. This means we need to send Reconfigure message > to > only the nodes in a particular link, not to all the nodes in the site. > > Thus, if we use All DHCP clients multicast address, most of the nodes > will unecessarily receive the Reconfigure-init message. > > * There are some list of Generic Error values like > AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned > > how to return this error value. We need an option or a field for > returning these generic error values. This option must be included in > the base-spec. > > * In solicit message, does the client need to send the number of IP > address needed for the IA, in the IA option? I think it is better to > send the requested number of IP address in the Ia option. If the > client > is asking "n" number of IP address and the server can offer only "m" > IP-addresses (m "n" IP address. This can become one criteria for selecting the server > to > send the DHCP Request message. > > >The server MUST include options to Advertise message containing any > address >that would be assigned to IAs contained in the Solicit > message format. > > 1. Is this similar to the DHCP OFFER in DHCPv4? > 2. If the client has asked "n" IP address, does the server need to > send > "n" address in the IA? (or) need to send the just the prefix? > 3. If the server does not have one or few of the requested > configuration > parameters asked by the client in ORO option, does the server need to > send the only the configuration parameters it have and leave the other > > options. (or) since it doesn't have some of the configuration > parameters, will it tollaly ignore the Solicit and don't send reply? > 4. If the server can offer only few IP-address (m) less than the > requested number of IP-address (n), does the server needs to respond > with the available number of IP-address (OR) doesn't send Advertise? > 5. If the server is sending the "n" IP Addresses in IA option in > Advertise message, it means that, these addresses should not be > assigned > to the other clients and is reserved for the client that has sent the > Solicit? > > Request message > _______________ > > 1. assume, the client has asked 2 IP address first time. After some > times, it needs another 3 IP-address in the same interface. This time, > > does it need to send a fresh empty IA? or it can ask for another 3 > IP-address in the same IA? > > a) If it has to send the fresh empty IA, how will the server maintain > the record of these IAs, since the IA sent at the first time and sent > next time will have the same DUID and subnet-prefix. Will the server > treat these two as different or same IAs? > > b) why empty IA is to be sent for requesting IP address? > > c) what does exactly the empty IA mean? In other words, what are the > fields to be filled in IA options for sending the empty IA. > > (eg):- If the client is requesting 3 IP-address, > I think these are fields which must be filled. > (1) option-code > (2) option-len > (3) IA-DUID > (4) num-addrs = 3 > > do the addr status, prefix length, IPv6 address, pref life time, val > life time should be present or filled with zeros? > > 2. If the client has sufficient scope to reach the server, then why > can't it send the Request message directly? Why is it mentioned in the > > draft that it should send the Request message to All DHCP Agents > Address? This situtation holds for renew and rebind message also. > > Release Message > _______________ > > For sending DHCP Release message, does the client include addresses to > > be released? (or) includes ONLY the address to be released? > > Authentication Option > _____________________ > > Why authentication option is to be included as the last option? > If it is included as the first option, it will be easier to > authenicate > first and in case, if authentication fails, it can directly reject the > > packet without processing further. > > Sending deprecated address > __________________________ > > Assume > 1. A network renumbering for a particular link has occured. The prefix > > 5ffe:: is changed to 3ffe:: > 2. An IA for a node in this link has following addresses, 5ffe::20 and > > 5ffe::21 > 3. Now reconfiguration has been triggered and the server has sent the > Reconfigure-init message to the client. > 4. Client has responded with DHCP Request. > > a) does the server has to delete the addresses 5ffe::20 and 5ffe::21 > from the IA and include 3ffe::20 and 3ffe:21 in the IA? > (or) > b) for graceful renumbering, it can add new IP-address 3ffe::20 and > 3ffe:21 to the IA along with the orginal 5ffe addresses? > In this case, i feel that the old prefix addresses (5ffe) should be > made > deprecated one with the prefered-lifetime = 0 and valid-lifetime = > some > grace period. I think this is a MUST one for renumbering. > > _______________________ > > * In the draft, in one section(12.3.2) , it is mentioned that, client > has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In > another section( WAIT collecting Advertise message. Since both the > variable has different default values, which is to be used? ------_=_NextPart_001_01C0ABE0.E3039260 Content-Type: text/html; charset="iso-8859-1" RE: questions on DHCPv6 -18 rev of draft

See comments below (BV>).

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, March 13, 2001 10:23 AM
To: DHCPv6 discussion list
Subject: Re: questions on DHCPv6 -18 rev of draft


> "Bernie Volz (EUD)" wrote:
>
> Some comments regarding your questions:
>
> Fragmentation - This problem doesn't exist. The IPv6 layer will
> reassemble the packet. If the packet is multicast on the link, the
> other systems on that link in the destination multicast group will all
> reassemble the packet before processing it. So, whether it is a relay
> agent or a server doesn't matter. Also, if the relay is unicasting the
> packet to a server, same thing happens (it will be reassembled). This
> fragmentation is NOT something that the DHCP Client code does - but
> something that happens at the IPv6 layer. So, if the -18 text isn't
> clear about this, we need to fix it.

Yes. I think the draft has to make clear this.

>
> DUID - How it is generated is still the $64,000 question. There have
> been some proposals in discussions.
>
> All DHCP Clients Multicast - I agree, it should be link local. This
> hasn't yet been fully explored. It appears, from the -18 draft, that
> the server somehow communicates the client to tell it what Multicast
> group to join, but I think that has flaws in it. (I'm in the process
> of writing up some review comments as well in preparation for the
> conference call and this was one of my issues.)
>

I feel that having All DHCP Clients Multicast address will be only an
additional overhead. Consider the following situation.
1. Consider a site with links m,n,o,p. "p" has been renumbered.
2. The server will send the reconfigure-init message to the All DHCP
Client Site local multicast address.
Since this is an site-scoped address, all the clients in links m,n,o,p
will respond with DHCP Request, flooding the network. But, the server
actually wanted the clients in link "p" to respond.

If we define All DHCP Client Multicast address as a link-local one,
then, how wiil the server sends the reconfigure-init message to the
clients in the links which are not directly connected to the server.

BV> The DHCP Server needs to communicate through the relays. The DHCP Server
BV> must either be preconfigured with a list of the relays or could learn
BV> the relays (though that isn't as good if a server is starting cold as
BV> it can't trigger reconfigurations until it has learned of the relays).

I feel that, instead of defining a multicast address for this purpose,
if a range of multicast address of site-local scope is specified, then
the server can allocate one Reconfigure multicast address for one group.
(nodes belonging to one/two links can form a group). Thus, it prevents
other applications from using these multicast addresses.

In the draft it is said that, Reconfigure-int MAY contain ORO option. In
case, if it is not there, what are the options that the client has to
send in the Request message? I feel that Reconfigure-init MUST contain
ORO option to specify the client the options/parameters that has been
changed. Then only, the client can request for those options.

BV> I think the client should always send a full Request regardless of
BV> what the ORO options are in the Reconfigure-Init. That way, it can be
BV> sure to get complete information.

> Solicit message - The client just sends whatever IA option(s) it would
> send with a Request. This allows the server to respond with what it
> would assign on receipt of the Request. And, yes this is very similar
> to the DHCP DISCOVER/OFFER. The reason is that the client may need
> this information to make a decision as to which Advertise it will
> accept.
>
> Note that the specification (12.3.1) says: "all of the IAs MUST be
> empty" (when creating the Solicit).
>
> I believe that the server should reply even if it can't honor all of
> the options in the ORO - the client can decide which to take based on
> what it receives (if it needs a particular option, it can discard the
> ones without it). That's what we do in DHCPv4.
>
> If the server Advertises addresses, it should behave similar to
> DHCPv4's OFFER in that the server SHOULD not reassign these addresses
> for a short time to 'reserve' them for the client. But, it is only a
> SHOULD and not a MUST (the server may change the addresses in the
> REPLY).

The short time that the server 'reserve' the addresses needs to be
defined.

BV> Perhaps a default can be provided (I don't recall the DHCPv4 specification
BV> having this value). But I think it can also be left to the implementor (or
BV> as a configuration parameter on the server. This partially depends on how
BV> short you are on addresses (and with IPv6 that isn't likely to be an issue).

>
> Note that when the Client constructs the Request "The list of
> addresses in each included IA MUST be empty." (13.3.1). Therefore,
> unless the server takes steps to 'reserve' the addresses, the client
> should have forgotten about them.
>
> Request message (client wants more addresss) - If a client wants new
> addresses, it must use a new IA. This new DUID must be different than
> the previous. The DUID really is a client identifier/interface
> identifier/address request identifier. I think this has gotten lost in
> the draft text.

Why do we need the seperate IA for the getting new addresses. Is there
any specific reason for not sending the request for new addresses in the
same IA?

BV> How does the server know the client wants more addresses? The num-addr
BV> field is supposed to reflect the number of addresses that follow (not
BV> the number that is requested) from my understanding.

>
> The reason for sending *ALL* client requests via the multicast
> mechanism is such that if a relay agent is between the client and
> server IT WILL ALWAYS BE between the client and server. Therefore,
> things like the DHCPv4 Relay Agent options can always be inserted in
> the clients requests and the server always has complete information.
> This is actually a nice solution. There are also others (such as if
> there are failover partners, they can respond on behalf of each other
> if they know the target server is down). There is of course a cost,
> but it is rather low. One option we could consider (though at the lost
> of some potential features such as the failover one) is allowing a
> client to unicast to the server IF AND ONLY IF the server is on the
> link (ie, the server's address is a link-local). For in that case, no
> relay options would be added. But, I'm not in favor of this.

yes. this is ok. It will be better to use multicast instead of unicast.

>
> Release message - A client can release one or many addresses (either
> in one or multiple IAs). It need not release all of the addresses in a
> single IA.
>
> Sending deprecated address - I would expect that the server to do (b)
> - include both the old addresses (with lifetimes adjusted) and the
> new. However, it may also do (a) if the previous lifetimes given the
> client are still applicable and there is no need for the server to
> update them (since the client can use those addresses until the valid
> lifetime expires).

thanks for clarifying the doubts.
Vijay.

>
> I'm sure I missed a few of your questions. Good comments.
>
> - Bernie Volz
>   Ericsson
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Monday, March 12, 2001 7:06 PM
> To: DHCPv6 discussion list
> Subject: questions on DHCPv6 -18 rev of draft
>
> Hi,
> I have few questions regarding the -18 rev of DHCPv6 draft. I will be
> attending the design telecon. let me know your comments about these
> issues.
> Regrads,
> Vijay
>
> questions
> ---------
>
> * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6
> implmentation has to take care of the fragmentation.
> Assume the client has fragmented the packet in to two packets. The
> server will
> read the first packet correctly, since it is in proper packet format.
> Then, the second packet will be discarded, since it has only the
> remaining
> content of the previously sent packet.
> This is because, the server doesn't know that whether the packet
> recieved is
> correct one or the later part of the  prviously sent fragmented
> packet.
> Do we need to have an additional message type (or) a field speciying
> the
> "next fragment" for transmission of the fragemented packet?
>
> * How DUID is generated? what is its format?
>
> * I think we don't need site scoped "All DHCP Clients" multicast
> address
> for sending reconfigure messages. Since, renumbering of network takes
> place per link basis. This means we need to send Reconfigure message
> to
> only the nodes in a particular link, not to all the nodes in the site.
>
> Thus, if we use All DHCP clients multicast address, most of the nodes
> will unecessarily receive the Reconfigure-init  message.
>
> * There are some list of Generic Error values like
> AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned
>
> how to return this error value. We need an option or a field for
> returning these generic error values. This option must be included in
> the base-spec.
>
> * In solicit message, does the client need to send the number of IP
> address needed for the IA, in the IA option? I think it is better to
> send the requested number of IP address in the Ia option. If the
> client
> is asking "n" number of IP address and the server can offer only "m"
> IP-addresses (m<n), then the client can choose better server offering
> "n" IP address. This can become one criteria for selecting the server
> to
> send the DHCP Request message.
>
> >The server MUST include options to Advertise message containing any
> address >that would be assigned to IAs contained in the Solicit
> message format.
>
> 1. Is this similar to the DHCP OFFER in DHCPv4?
> 2. If the client has asked "n" IP address, does the server need to
> send
> "n" address in the IA? (or) need to send the just the prefix?
> 3. If the server does not have one or few of the requested
> configuration
> parameters asked by the client in ORO option, does the server need to
> send the only the configuration parameters it have and leave the other
>
> options. (or) since it doesn't have some of the configuration
> parameters, will it tollaly ignore the Solicit and don't send reply?
> 4. If the server can offer only few IP-address (m) less than the
> requested number of IP-address (n), does the server needs to respond
> with the available number of IP-address (OR) doesn't send Advertise?
> 5. If the server is sending the "n" IP Addresses in IA option in
> Advertise message, it means that, these addresses should not be
> assigned
> to the other clients and is reserved for the client that has sent the
> Solicit?
>
> Request message
> _______________
>
> 1. assume, the client has asked 2 IP address first time. After some
> times, it needs another 3 IP-address in the same interface. This time,
>
> does it need to send a fresh empty IA? or it can ask for another 3
> IP-address in the same IA?
>
> a) If it has to send the fresh empty IA, how will the server maintain
> the record of these IAs, since the IA sent at the first time and sent
> next time will have the same DUID and subnet-prefix. Will the server
> treat these two as different or same IAs?
>
> b) why empty IA is to be sent for requesting IP address?
>
> c) what does exactly the empty IA mean? In other words, what are the
> fields to be filled in IA options for sending the empty IA.
>
> (eg):- If the client is requesting 3 IP-address,
> I think these are fields which must be filled.
> (1) option-code
> (2) option-len
> (3) IA-DUID
> (4) num-addrs = 3
>
> do the addr status, prefix length, IPv6 address, pref life time, val
> life time should be present or filled with zeros?
>
> 2. If the client has sufficient scope to reach the server, then why
> can't it send the Request message directly? Why is it mentioned in the
>
> draft that it should send the Request message to All DHCP Agents
> Address? This situtation holds for renew and rebind message also.
>
> Release Message
> _______________
>
> For sending DHCP Release message, does the client include addresses to
>
> be released? (or) includes ONLY the address to be released?
>
> Authentication Option
> _____________________
>
> Why authentication option is to be included as the last option?
> If it is included as the first option, it will be easier to
> authenicate
> first and in case, if authentication fails, it can directly reject the
>
> packet without processing further.
>
> Sending deprecated address
> __________________________
>
> Assume
> 1. A network renumbering for a particular link has occured. The prefix
>
> 5ffe:: is changed to 3ffe::
> 2. An IA for a node in this link has following addresses, 5ffe::20 and
>
> 5ffe::21
> 3. Now reconfiguration has been triggered and the server has sent the
> Reconfigure-init message to the client.
> 4. Client has responded with DHCP Request.
>
> a) does the server has to delete the addresses 5ffe::20 and 5ffe::21
> from the IA and include 3ffe::20 and 3ffe:21 in the IA?
> (or)
> b) for graceful renumbering, it can add new IP-address 3ffe::20 and
> 3ffe:21 to the IA along with the orginal 5ffe addresses?
> In this case, i feel that the old prefix addresses (5ffe) should be
> made
> deprecated one with the prefered-lifetime = 0 and valid-lifetime =
> some
> grace period. I think this is a MUST one for renumbering.
>
> _______________________
>
> * In the draft, in one section(12.3.2) , it is mentioned that, client
> has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In
> another section( WAIT collecting Advertise message. Since both the
> variable has different default values, which is to be used?

------_=_NextPart_001_01C0ABE0.E3039260-- From owner-dhcp-v6@bucknell.edu Tue Mar 13 13:01:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25016; Tue, 13 Mar 2001 13:01:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DHwaL25293; Tue, 13 Mar 2001 12:58:36 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2DHwYL16974 for ; Tue, 13 Mar 2001 12:58:34 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2DHwXi06575 for ; Tue, 13 Mar 2001 11:58:33 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2DHwWX19623 for ; Tue, 13 Mar 2001 11:58:33 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Mar 13 11:59:48 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 11:59:47 -0600 Message-ID: <66F66129A77AD411B76200508B65AC691F659D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Server Preference Value in DHCPv6 Date: Tue, 13 Mar 2001 11:59:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABE7.608F1A00" 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 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_001_01C0ABE7.608F1A00 Content-Type: text/plain; charset="iso-8859-1" Suresh: These are good questions. I believe the simple answer is that it is for administrators to decide (whatever factors they want to use). You might think of it as if you have three servers servicing a network for redundancy (no failover type protocol), you want clients to get answers from the highest preference server first. Note that a server can use different preferences on different networks. So, in the above three server situation, I could have all servers servicing all networks, but assign the first server highest priority over two networks, another highest over some others, and the third highest over the remaining. The preference issue has gotten a bit messy, IMHO. Mainly because we now allow the Advertise to include options (such as the addresses offerred to the client). The problem here is what if a client receives three Advertisements but the one with the addresses (or other options) it really wants (whatever that means) is given the lowest preference? Can it use that one? Or MUST it use the highest? The exact wording (if memory serves) actually uses SHOULD and MAY, so I guess the preferences are already watered down some. I still think it has value. But, I think the client policies will generally be to chose the highest preference server that offers the "services" desired. (That factors in what the server returns as options in the Advertise.) - Bernie -----Original Message----- From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] Sent: Tuesday, March 13, 2001 1:09 AM To: DHCPv6 discussion list Subject: Server Preference Value in DHCPv6 I have a few doubts regarding the "preference" field. I would like to know the importance of server preference value from the client perspective. In draft 17 it is mentioned that the setting of a server preference value SHOULD be allowed by administrator. What decides a server to be of "high prefernce" and how does an administrator selects a value. Does it depend upon the number of addresses that a server can give (or) the link/relay through which the server receive the SOLICIT messages (or) the efficiency of the machine ( ???? ) (or) just an administrators option which is constant throughout. thanks and regards Suresh Kodati IBM India Software Labs Email:- skodati@in.ibm.com ------_=_NextPart_001_01C0ABE7.608F1A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Server Preference Value in DHCPv6

Suresh:

These are good questions. I believe the simple answer = is that it is for administrators to decide (whatever factors they want = to use). You might think of it as if you have three servers servicing a = network for redundancy (no failover type protocol), you want clients to = get answers from the highest preference server first.

Note that a server can use different preferences on = different networks. So, in the above three server situation, I could = have all servers servicing all networks, but assign the first server = highest priority over two networks, another highest over some others, = and the third highest over the remaining.

The preference issue has gotten a bit messy, IMHO. = Mainly because we now allow the Advertise to include options (such as = the addresses offerred to the client). The problem here is what if a = client receives three Advertisements but the one with the addresses (or = other options) it really wants (whatever that means) is given the = lowest preference? Can it use that one? Or MUST it use the = highest?

The exact wording (if memory serves) actually uses = SHOULD and MAY, so I guess the preferences are already watered down = some.

I still think it has value. But, I think the client = policies will generally be to chose the highest preference server that = offers the "services" desired. (That factors in what the = server returns as options in the Advertise.)

- Bernie

-----Original Message-----
From: skodati@in.ibm.com [mailto:skodati@in.ibm.com]=
Sent: Tuesday, March 13, 2001 1:09 AM
To: DHCPv6 discussion list
Subject: Server Preference Value in DHCPv6



I have a few doubts regarding the = "preference" field.  I would like to know
the importance of server preference value from the = client perspective.

In draft 17 it is mentioned that the setting of a = server preference value
SHOULD be allowed by administrator. What decides a = server to be of "high
prefernce" and how  does an administrator = selects a value.
Does it depend upon
          &nb= sp;       the number of addresses that a = server can give
     (or) the link/relay through = which the server receive the SOLICIT
messages
     (or) the efficiency of the = machine ( ???? )
     (or) just an administrators = option which is constant throughout.

thanks and regards
   Suresh Kodati
   IBM India Software Labs
  Email:- skodati@in.ibm.com

------_=_NextPart_001_01C0ABE7.608F1A00-- From owner-dhcp-v4@bucknell.edu Tue Mar 13 16:32:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28651 for ; Tue, 13 Mar 2001 16:32:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2DLNdL14789; Tue, 13 Mar 2001 16:23:39 -0500 (EST) 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 f2DLNUL10779 for ; Tue, 13 Mar 2001 16:23:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA16190 for ; Tue, 13 Mar 2001 16:23:11 -0500 (EST) Message-Id: <4.3.2.7.2.20010313161802.03585b20@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 16:23:00 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Tentative agenda for DHC WG meeting, 3/19 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 If you have an agenda item for the 1530 3/19 DHC WG meeting, please contact me now so I can add it to the agenda. Here's the current agenda: Agenda bashing Announcements from the chair Authentication option to Proposed Standard Device class agent options Woundy Failover Kinnear Leasequery Kinnear Subnet selection sub-option Kinnear VPN-id and VPN-id sub-option Kinnear DHCP-DNS interaction - new drafts (?) Classless static routes (?) Option concatenation (?) Items marked (?) concern recently published drafts, and are awaiting confirmation from the authors. - Ralph From owner-dhcp-v6@bucknell.edu Wed Mar 14 00:26:14 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05130; Wed, 14 Mar 2001 00:26:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2E5NNL25796; Wed, 14 Mar 2001 00:23:23 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2E5N9L25356 for ; Wed, 14 Mar 2001 00:23:09 -0500 (EST) Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id QAA242804 for ; Wed, 14 Mar 2001 16:10:18 +1100 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m3/NCO v4.95) with SMTP id QAA25442 for ; Wed, 14 Mar 2001 16:21:59 +1100 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A0F.001D77C1 ; Wed, 14 Mar 2001 16:21:52 +1100 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Wed, 14 Mar 2001 10:36:03 +0530 Subject: Re: options in DHCP SOLICIT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Iam sorry for my previous mail, posted with this subject.. forgive me for the incomvenience Suresh Kodati From owner-dhcp-v6@bucknell.edu Wed Mar 14 00:27:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05149; Wed, 14 Mar 2001 00:27:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2E5RXL12246; Wed, 14 Mar 2001 00:27:33 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2E5RPL21511 for ; Wed, 14 Mar 2001 00:27:25 -0500 (EST) Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id QAA157290 for ; Wed, 14 Mar 2001 16:17:47 +1100 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.95) with SMTP id QAA52008 for ; Wed, 14 Mar 2001 16:27:07 +1100 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A0F.001D555C ; Wed, 14 Mar 2001 16:20:23 +1100 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Wed, 14 Mar 2001 10:34:05 +0530 Subject: Re: options in DHCP SOLICIT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Prabha This time your resume is looking nice, and your contribution for each project is quite clear now. Think of including your percentage of marks in degree some companies are particular about the academic career too. I prefer removing 'or' between the contact number and your email id on the top. Rest all are looking good for me.. ALL THE BEST thanks and regards Suresh Kodati IBM India Software Labs Airport Road Bangalore 560 017 INDIA Ph:- 5262355 Ext 2719 Email:- skodati@in.ibm.com From owner-dhcp-v6@bucknell.edu Wed Mar 14 08:25:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23042; Wed, 14 Mar 2001 08:25:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EDLjL10578; Wed, 14 Mar 2001 08:21:45 -0500 (EST) 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 f2EDLeL04345 for ; Wed, 14 Mar 2001 08:21:40 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id C7BF51AFE for ; Wed, 14 Mar 2001 05:21:27 -0800 (PST) Received: from india.hp.com (vijayak@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 SAA20563 for ; Wed, 14 Mar 2001 18:49:15 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3AAF70D4.904C2C04@india.hp.com> Date: Wed, 14 Mar 2001 18:53:33 +0530 From: Vijay Bhaskar A K Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: questions on DHCPv6 -18 rev of draft References: <66F66129A77AD411B76200508B65AC691F6593@eambunt705.ena-east.ericsson.se> 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 Hi Bernie, see my comments below (VB>) > "Bernie Volz (EUD)" wrote: > > See comments below (BV>). > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Tuesday, March 13, 2001 10:23 AM > To: DHCPv6 discussion list > Subject: Re: questions on DHCPv6 -18 rev of draft > > > "Bernie Volz (EUD)" wrote: > > > > Some comments regarding your questions: > > > > Fragmentation - This problem doesn't exist. The IPv6 layer will > > reassemble the packet. If the packet is multicast on the link, the > > other systems on that link in the destination multicast group will > all > > reassemble the packet before processing it. So, whether it is a > relay > > agent or a server doesn't matter. Also, if the relay is unicasting > the > > packet to a server, same thing happens (it will be reassembled). > This > > fragmentation is NOT something that the DHCP Client code does - but > > something that happens at the IPv6 layer. So, if the -18 text isn't > > clear about this, we need to fix it. > > Yes. I think the draft has to make clear this. > > > > > DUID - How it is generated is still the $64,000 question. There have > > > been some proposals in discussions. > > > > All DHCP Clients Multicast - I agree, it should be link local. This > > hasn't yet been fully explored. It appears, from the -18 draft, that > > > the server somehow communicates the client to tell it what Multicast > > > group to join, but I think that has flaws in it. (I'm in the process > > > of writing up some review comments as well in preparation for the > > conference call and this was one of my issues.) > > > > I feel that having All DHCP Clients Multicast address will be only an > additional overhead. Consider the following situation. > 1. Consider a site with links m,n,o,p. "p" has been renumbered. > 2. The server will send the reconfigure-init message to the All DHCP > Client Site local multicast address. > Since this is an site-scoped address, all the clients in links m,n,o,p > > will respond with DHCP Request, flooding the network. But, the server > actually wanted the clients in link "p" to respond. > > If we define All DHCP Client Multicast address as a link-local one, > then, how wiil the server sends the reconfigure-init message to the > clients in the links which are not directly connected to the server. > > BV> The DHCP Server needs to communicate through the relays. The DHCP > Server > BV> must either be preconfigured with a list of the relays or could > learn > BV> the relays (though that isn't as good if a server is starting cold > as > BV> it can't trigger reconfigurations until it has learned of the > relays). VB> There is no need of preconfiguring the server. It can record the relay VB> information from the previous Relay-forward messages. > > I feel that, instead of defining a multicast address for this purpose, > > if a range of multicast address of site-local scope is specified, then > > the server can allocate one Reconfigure multicast address for one > group. > (nodes belonging to one/two links can form a group). Thus, it prevents > > other applications from using these multicast addresses. > > In the draft it is said that, Reconfigure-int MAY contain ORO option. > In > case, if it is not there, what are the options that the client has to > send in the Request message? I feel that Reconfigure-init MUST contain > > ORO option to specify the client the options/parameters that has been > changed. Then only, the client can request for those options. > > BV> I think the client should always send a full Request regardless of > > BV> what the ORO options are in the Reconfigure-Init. That way, it can > be > BV> sure to get complete information. VB> Assume, in future, we have defined 100 options. The client has to send the VB> Request with all the 100 options asked? In case, only 2 parameters has been VB> changed and the clients will be requesting for 100 configuration parameters. VB> The message size will become very large. I think i we make the ORO option in VB> Reconfigure-init as mandatory, we can prevent this. > > > Solicit message - The client just sends whatever IA option(s) it > would > > send with a Request. This allows the server to respond with what it > > would assign on receipt of the Request. And, yes this is very > similar > > to the DHCP DISCOVER/OFFER. The reason is that the client may need > > this information to make a decision as to which Advertise it will > > accept. > > > > Note that the specification (12.3.1) says: "all of the IAs MUST be > > empty" (when creating the Solicit). > > > > I believe that the server should reply even if it can't honor all of > > > the options in the ORO - the client can decide which to take based > on > > what it receives (if it needs a particular option, it can discard > the > > ones without it). That's what we do in DHCPv4. > > > > If the server Advertises addresses, it should behave similar to > > DHCPv4's OFFER in that the server SHOULD not reassign these > addresses > > for a short time to 'reserve' them for the client. But, it is only a > > > SHOULD and not a MUST (the server may change the addresses in the > > REPLY). > > The short time that the server 'reserve' the addresses needs to be > defined. > > BV> Perhaps a default can be provided (I don't recall the DHCPv4 > specification > BV> having this value). But I think it can also be left to the > implementor (or > BV> as a configuration parameter on the server. This partially depends > on how > BV> short you are on addresses (and with IPv6 that isn't likely to be > an issue). VB> ok. i agree with this. > > > > > Note that when the Client constructs the Request "The list of > > addresses in each included IA MUST be empty." (13.3.1). Therefore, > > unless the server takes steps to 'reserve' the addresses, the client > > > should have forgotten about them. > > > > Request message (client wants more addresss) - If a client wants new > > > addresses, it must use a new IA. This new DUID must be different > than > > the previous. The DUID really is a client identifier/interface > > identifier/address request identifier. I think this has gotten lost > in > > the draft text. > > Why do we need the seperate IA for the getting new addresses. Is there > > any specific reason for not sending the request for new addresses in > the > same IA? > > BV> How does the server know the client wants more addresses? The > num-addr > BV> field is supposed to reflect the number of addresses that follow > (not > BV> the number that is requested) from my understanding. VB> This can be done very will the single IA. VB> Assume the IA has already 2 addresses. Now, the client wants another 3 VB> addresses. For requesting another 3 addresses, send the same IA option with VB> following. VB> 1. make num-addrs field as 5. VB> 2. Include already existing 2 addresses in the IA option with filled prefix VB> length, IPv6 address and preferred lifetime and valid life time values. VB> 3. For the remaining 3 address newly asked, fill the prefix length, IPv6 VB> address, pref-life time, valid-life time with zero and make the corresponding VB> addr status to ADDR_REQUEST indicating, the client is asking the address. VB> This has some advantages also. VB> 1. The DUID is need not to be generated for each and every request. VB> 2. The server can maintain the list of IP-address it is managing for a VB> particular interface of a node. This will minimize the number of records VB> maintained. > > > > > The reason for sending *ALL* client requests via the multicast > > mechanism is such that if a relay agent is between the client and > > server IT WILL ALWAYS BE between the client and server. Therefore, > > things like the DHCPv4 Relay Agent options can always be inserted in > > > the clients requests and the server always has complete information. > > > This is actually a nice solution. There are also others (such as if > > there are failover partners, they can respond on behalf of each > other > > if they know the target server is down). There is of course a cost, > > but it is rather low. One option we could consider (though at the > lost > > of some potential features such as the failover one) is allowing a > > client to unicast to the server IF AND ONLY IF the server is on the > > link (ie, the server's address is a link-local). For in that case, > no > > relay options would be added. But, I'm not in favor of this. > > yes. this is ok. It will be better to use multicast instead of > unicast. > > > > > Release message - A client can release one or many addresses (either > > > in one or multiple IAs). It need not release all of the addresses in > a > > single IA. > > > > Sending deprecated address - I would expect that the server to do > (b) > > - include both the old addresses (with lifetimes adjusted) and the > > new. However, it may also do (a) if the previous lifetimes given the > > > client are still applicable and there is no need for the server to > > update them (since the client can use those addresses until the > valid > > lifetime expires). > > thanks for clarifying the doubts. > Vijay. > > > > > I'm sure I missed a few of your questions. Good comments. > > > > - Bernie Volz > > Ericsson > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Monday, March 12, 2001 7:06 PM > > To: DHCPv6 discussion list > > Subject: questions on DHCPv6 -18 rev of draft > > > > Hi, > > I have few questions regarding the -18 rev of DHCPv6 draft. I will > be > > attending the design telecon. let me know your comments about these > > issues. > > Regrads, > > Vijay > > > > questions > > --------- > > > > * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 > > implmentation has to take care of the fragmentation. > > Assume the client has fragmented the packet in to two packets. The > > server will > > read the first packet correctly, since it is in proper packet > format. > > Then, the second packet will be discarded, since it has only the > > remaining > > content of the previously sent packet. > > This is because, the server doesn't know that whether the packet > > recieved is > > correct one or the later part of the prviously sent fragmented > > packet. > > Do we need to have an additional message type (or) a field speciying > > > the > > "next fragment" for transmission of the fragemented packet? > > > > * How DUID is generated? what is its format? > > > > * I think we don't need site scoped "All DHCP Clients" multicast > > address > > for sending reconfigure messages. Since, renumbering of network > takes > > place per link basis. This means we need to send Reconfigure message > > > to > > only the nodes in a particular link, not to all the nodes in the > site. > > > > Thus, if we use All DHCP clients multicast address, most of the > nodes > > will unecessarily receive the Reconfigure-init message. > > > > * There are some list of Generic Error values like > > AuthFailed,PoorlyFormed etc. are defined. But no where it is > mentioned > > > > how to return this error value. We need an option or a field for > > returning these generic error values. This option must be included > in > > the base-spec. > > > > * In solicit message, does the client need to send the number of IP > > address needed for the IA, in the IA option? I think it is better to > > > send the requested number of IP address in the Ia option. If the > > client > > is asking "n" number of IP address and the server can offer only "m" > > > IP-addresses (m offering > > "n" IP address. This can become one criteria for selecting the > server > > to > > send the DHCP Request message. > > > > >The server MUST include options to Advertise message containing any > > > address >that would be assigned to IAs contained in the Solicit > > message format. > > > > 1. Is this similar to the DHCP OFFER in DHCPv4? > > 2. If the client has asked "n" IP address, does the server need to > > send > > "n" address in the IA? (or) need to send the just the prefix? > > 3. If the server does not have one or few of the requested > > configuration > > parameters asked by the client in ORO option, does the server need > to > > send the only the configuration parameters it have and leave the > other > > > > options. (or) since it doesn't have some of the configuration > > parameters, will it tollaly ignore the Solicit and don't send reply? > > > 4. If the server can offer only few IP-address (m) less than the > > requested number of IP-address (n), does the server needs to respond > > > with the available number of IP-address (OR) doesn't send Advertise? > > > 5. If the server is sending the "n" IP Addresses in IA option in > > Advertise message, it means that, these addresses should not be > > assigned > > to the other clients and is reserved for the client that has sent > the > > Solicit? > > > > Request message > > _______________ > > > > 1. assume, the client has asked 2 IP address first time. After some > > times, it needs another 3 IP-address in the same interface. This > time, > > > > does it need to send a fresh empty IA? or it can ask for another 3 > > IP-address in the same IA? > > > > a) If it has to send the fresh empty IA, how will the server > maintain > > the record of these IAs, since the IA sent at the first time and > sent > > next time will have the same DUID and subnet-prefix. Will the server > > > treat these two as different or same IAs? > > > > b) why empty IA is to be sent for requesting IP address? > > > > c) what does exactly the empty IA mean? In other words, what are the > > > fields to be filled in IA options for sending the empty IA. > > > > (eg):- If the client is requesting 3 IP-address, > > I think these are fields which must be filled. > > (1) option-code > > (2) option-len > > (3) IA-DUID > > (4) num-addrs = 3 > > > > do the addr status, prefix length, IPv6 address, pref life time, val > > > life time should be present or filled with zeros? > > > > 2. If the client has sufficient scope to reach the server, then why > > can't it send the Request message directly? Why is it mentioned in > the > > > > draft that it should send the Request message to All DHCP Agents > > Address? This situtation holds for renew and rebind message also. > > > > Release Message > > _______________ > > > > For sending DHCP Release message, does the client include addresses > to > > > > be released? (or) includes ONLY the address to be released? > > > > Authentication Option > > _____________________ > > > > Why authentication option is to be included as the last option? > > If it is included as the first option, it will be easier to > > authenicate > > first and in case, if authentication fails, it can directly reject > the > > > > packet without processing further. > > > > Sending deprecated address > > __________________________ > > > > Assume > > 1. A network renumbering for a particular link has occured. The > prefix > > > > 5ffe:: is changed to 3ffe:: > > 2. An IA for a node in this link has following addresses, 5ffe::20 > and > > > > 5ffe::21 > > 3. Now reconfiguration has been triggered and the server has sent > the > > Reconfigure-init message to the client. > > 4. Client has responded with DHCP Request. > > > > a) does the server has to delete the addresses 5ffe::20 and 5ffe::21 > > > from the IA and include 3ffe::20 and 3ffe:21 in the IA? > > (or) > > b) for graceful renumbering, it can add new IP-address 3ffe::20 and > > 3ffe:21 to the IA along with the orginal 5ffe addresses? > > In this case, i feel that the old prefix addresses (5ffe) should be > > made > > deprecated one with the prefered-lifetime = 0 and valid-lifetime = > > some > > grace period. I think this is a MUST one for renumbering. > > > > _______________________ > > > > * In the draft, in one section(12.3.2) , it is mentioned that, > client > > has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. > In > > another section( WAIT collecting Advertise message. Since both the > > variable has different default values, which is to be used? -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ From owner-dhcp-v6@bucknell.edu Wed Mar 14 09:45:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24165; Wed, 14 Mar 2001 09:45:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EEeqL06405; Wed, 14 Mar 2001 09:40:52 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EEehL01004 for ; Wed, 14 Mar 2001 09:40:43 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2EEaKi26091 for ; Wed, 14 Mar 2001 08:36:24 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2EEaJP13289 for ; Wed, 14 Mar 2001 08:36:19 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Mar 14 08:36:01 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 08:37:44 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB82D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Reducing the DHCPv6 packet size? Date: Wed, 14 Mar 2001 08:37:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC94.5360E450" 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 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_001_01C0AC94.5360E450 Content-Type: text/plain; charset="iso-8859-1" A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ... Do we really need to carry the client-link-local-address in most Client/Server interactions? 1) The relay or server on the local link can simply use the source address of the packet. 2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet. 3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet. 4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum). What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable. All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not). So, the proposed new headers would be: The DHCP message header: 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 | preference | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Relay-forward/Relay-reply message 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 | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | client-link-local-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | options (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Bernie Volz Ericsson ------_=_NextPart_001_01C0AC94.5360E450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reducing the DHCPv6 packet size?

A question/suggestion about = reducing the DHCPv6 packet size (by 16 bytes) ...

Do we really need to carry the = client-link-local-address in most Client/Server interactions?

1) The relay or server on the = local link can simply use the source address of the packet.
2) A relay will need to include = the client-link-local-address when it sends a Relay-Forward to a = server, but that can be added into the relay's packet.

3) A server will need to include = the client-link-local-address when it sends a Relay-Reply to a server, = but that again can be added into the relay's packet.

4) If authentication (of = whatever type) wants to cover the client-link-local-address, that can = be added to some pseudo-header (much like TCP and UDP have the source = and destination address in the pseudo-header when they calculate the = checksum).

What this means is that client = <--> agent interactions would save 16 bytes/packet and the Relay = <--> server interaction packets would be the same size. For = 3GPP/UMTS networks, this would save bytes over the air interface which = is desireable.

All IP stacks (whether IPv4 or = IPv6) must always provide the SOURCE address of a packet on a receive = operation (such as socket's recvfrom). And, I can't imagine that the = address selection logic for IPv6 would ever suggest using a = non-link-local address for the IPv6 header source address if the = destination address is a link-local-address (whether multicast or = not).

So, the proposed new headers = would be:


   The DHCP message = header:

      = 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   |  preference   = |         = transaction-ID        |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ; = server-address         &nbs= p;           &nbs= p;  |
     = |            = ;            = ;  (16 = octets)           = ;            = ;   |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
     = .           &nbs= p;           &nbs= p;    = options           = ;            = ;     .
     = |            = ;            = ;  = (variable)          &n= bsp;           &n= bsp;    |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=


Relay-forward/Relay-reply = message

      = 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   | prefix length = |            = ;            = ;       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      &nb= sp;           &nb= sp;            = |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ; = relay-address          = ;            = ;   |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ;       = |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      &nb= sp;           &nb= sp;            = |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;       = client-link-local-address        = ;           |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ;       = |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      &nb= sp;           &nb= sp;            = |
     = |            = options (variable number and length)   = ....        |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

- Bernie Volz
  Ericsson

------_=_NextPart_001_01C0AC94.5360E450-- From owner-dhcp-v6@bucknell.edu Wed Mar 14 09:49:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24248; Wed, 14 Mar 2001 09:49:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EEn0L25536; Wed, 14 Mar 2001 09:49:00 -0500 (EST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EEmtL32054 for ; Wed, 14 Mar 2001 09:48:55 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA27218 for ; Wed, 14 Mar 2001 07:48:54 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA22278 for ; Wed, 14 Mar 2001 07:44:05 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for dhcp-v6@bucknell.edu; Wed, 14 Mar 2001 07:48:47 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id PAA23942 for dhcp-v6@bucknell.edu.DELIVER; Wed, 14 Mar 2001 15:48:45 +0100 (MET) Received: from crm.mot.com (labussie@magda.crm.mot.com [140.101.173.48]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id PAA23879 for ; Wed, 14 Mar 2001 15:48:44 +0100 (MET) Sender: owner-dhcp-v6@bucknell.edu Message-Id: <3AAF84CC.C31C5A28@crm.mot.com> Date: Wed, 14 Mar 2001 15:48:44 +0100 From: Jerome Labussiere Reply-To: Jerome.Labussiere@crm.mot.com Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.74C-CRM-4.7_2.2 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Question about REBIND message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: labussie@crm.mot.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello In the -18 rev, it is said that the client send the REBIND message at T2 (section 16.2) to 'any available server' in order to extend the lifetimes of an IA, if the primary server has not responded at T1. I guess 'any available server' means any server which can receive the message (because it is onlink or via a relay). However, according to section 13.4.4 the server can successfully extend the lifetimes only if it has a binding for this client. Does that mean that the client should follow the REQUEST/REPLY process for a single IA with many servers ? If so, what T1 and T2 and lifetimes should we consider ? If not, how the rebinding is possible ? Assume a server with no binding returns an IA Empty/NoBinding REPLY message before a server with a binding. How should we handle this ? Should we wait for an other reply ? How much time ? Same thing for all messages with 0 in the server-adress field. I don't get the idea. Please, could you explain. Thanks Jerome Labussiere From owner-dhcp-v6@bucknell.edu Wed Mar 14 10:41:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26160; Wed, 14 Mar 2001 10:41:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EFeeL07632; Wed, 14 Mar 2001 10:40:40 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EFebL24022 for ; Wed, 14 Mar 2001 10:40:37 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EFgRw16706 for ; Wed, 14 Mar 2001 09:42:27 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 09:40:18 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 09:40:18 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Question about REBIND message Date: Wed, 14 Mar 2001 09:40:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 > -----Original Message----- > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > Sent: Wednesday,March 14,2001 9:49 AM > To: DHCPv6 discussion list > Subject: Question about REBIND message > > > Hello > > In the -18 rev, it is said that the client send the REBIND > message at T2 > (section 16.2) to 'any available server' in order to extend the > lifetimes of an IA, if the primary server has not responded at T1. I > guess 'any available server' means any server which can receive the > message (because it is onlink or via a relay). However, according to > section 13.4.4 the server can successfully extend the > lifetimes only if > it has a binding for this client. thats correct. the idea is if another server thru some other means can do this we don't want to prohibit the function for rebind. > > Does that mean that the client should follow the REQUEST/REPLY process > for a single IA with many servers ? If so, what T1 and T2 and > lifetimes > should we consider ? If not, how the rebinding is possible ? the t1 and t2 have a default case too. so they always work. the client will work with a server. but suppose that server copys all client records to another server. when the rebind happens the other server could respond. > > Assume a server with no binding returns an IA Empty/NoBinding REPLY > message before a server with a binding. How should we handle this ? > Should we wait for an other reply ? How much time ? Same thing for all > messages with 0 in the server-adress field. the client should react immediately is my view. this is a case where we don't want mobile nodes hanging out. clients can always do policing of packets esp mobile nodes. /jim > > From owner-dhcp-v6@bucknell.edu Wed Mar 14 10:41:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26161; Wed, 14 Mar 2001 10:41:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EFaKL02506; Wed, 14 Mar 2001 10:36:20 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EFZqL07993 for ; Wed, 14 Mar 2001 10:35:52 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EFZWg29818 for ; Wed, 14 Mar 2001 09:35:42 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 14 Mar 2001 09:35:30 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 09:35:29 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Reducing the DHCPv6 packet size? Date: Wed, 14 Mar 2001 09:35:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC9C.6590D4C0" 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 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_001_01C0AC9C.6590D4C0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday,March 14,2001 9:38 AM To: DHCPv6 discussion list Subject: Reducing the DHCPv6 packet size? A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ... Do we really need to carry the client-link-local-address in most Client/Server interactions? [JPB2] I think absolutely. 1) The relay or server on the local link can simply use the source address of the packet. [JPB2] We were down this path. Doing this requires me to used the v6 advanced api or sysct or confget sys call. 2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet. [JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract. 3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet. [JPB2] This adds new state to our new relay paradigm and more code as above. 4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum). [JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA. The link-local is inherent to IPv6 we must have it. What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable. [JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol. also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units. All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not). So, the proposed new headers would be: The DHCP message header: 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 | preference | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Relay-forward/Relay-reply message 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 | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | client-link-local-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | options (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Bernie Volz Ericsson [JPB2] I don't believe your arguments are strong enough to change the spec. There is a reason why we are here today. ------_=_NextPart_001_01C0AC9C.6590D4C0 Content-Type: text/html; charset="iso-8859-1" Reducing the DHCPv6 packet size?
 
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday,March 14,2001 9:38 AM
To: DHCPv6 discussion list
Subject: Reducing the DHCPv6 packet size?

A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ...

Do we really need to carry the client-link-local-address in most Client/Server interactions?
[JPB2] I think absolutely.   

1) The relay or server on the local link can simply use the source address of the packet.
[JPB2] We were down this path.  Doing this requires me to used the v6 advanced api or sysct or confget sys call. 
2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet.
[JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract. 

3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet.
[JPB2] This adds new state to our new relay paradigm and more code as above. 

4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum).
[JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA.  The link-local is inherent to IPv6 we must have it. 

What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable.
[JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol.   also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units. 

All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not).

So, the proposed new headers would be:


   The DHCP message header:

      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   |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Relay-forward/Relay-reply message

      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   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                   client-link-local-address                   |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Bernie Volz
  Ericsson
[JPB2] I don't believe your arguments are strong enough to change the spec.  There is a reason why we are here today. 

------_=_NextPart_001_01C0AC9C.6590D4C0-- From owner-dhcp-v6@bucknell.edu Wed Mar 14 12:13:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28406; Wed, 14 Mar 2001 12:13:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EH7wL28745; Wed, 14 Mar 2001 12:07:58 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EH7kL09663 for ; Wed, 14 Mar 2001 12:07:46 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA10272 for ; Wed, 14 Mar 2001 10:07:44 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA00536 for ; Wed, 14 Mar 2001 10:07:43 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for dhcp-v6@bucknell.edu; Wed, 14 Mar 2001 10:07:21 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id SAA18573 for dhcp-v6@bucknell.edu.DELIVER; Wed, 14 Mar 2001 18:07:17 +0100 (MET) Received: from crm.mot.com (labussie@magda.crm.mot.com [140.101.173.48]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id SAA18542 for ; Wed, 14 Mar 2001 18:07:16 +0100 (MET) Sender: owner-dhcp-v6@bucknell.edu Message-Id: <3AAFA544.7CF06988@crm.mot.com> Date: Wed, 14 Mar 2001 18:07:16 +0100 From: Jerome Labussiere Reply-To: Jerome.Labussiere@crm.mot.com Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.74C-CRM-4.7_2.2 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: Question about REBIND message References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: labussie@crm.mot.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Jim.Bound@nokia.com wrote: > > > -----Original Message----- > > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > > Sent: Wednesday,March 14,2001 9:49 AM > > To: DHCPv6 discussion list > > Subject: Question about REBIND message > > > > > > Hello > > > > In the -18 rev, it is said that the client send the REBIND > > message at T2 > > (section 16.2) to 'any available server' in order to extend the > > lifetimes of an IA, if the primary server has not responded at T1. I > > guess 'any available server' means any server which can receive the > > message (because it is onlink or via a relay). However, according to > > section 13.4.4 the server can successfully extend the > > lifetimes only if > > it has a binding for this client. > > thats correct. the idea is if another server thru some other means can do > this we don't want to prohibit the function for rebind. > > Assume a server with no binding returns an IA Empty/NoBinding REPLY > > message before a server with a binding. How should we handle this ? > > Should we wait for an other reply ? How much time ? Same thing for all > > messages with 0 in the server-adress field. > > the client should react immediately is my view. this is a case where we > don't want mobile nodes hanging out. clients can always do policing of > packets esp mobile nodes. > Ok, so the idea of REBIND is to try everything to keep a set of addresses. Still one dark point: About 'reacting immediately', I've the feeling that it works with one DHCP server in the domain. But with two ? For instance, if the client has a binding with server A. For a good reason, it has to send a CONFIRM message. Server A and server B receive the CONFIRM and answer. A returns a REPLY/status 0 and B returns a REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by the client and A's REPLY is received one or two ms after. If the client reacts immediately, according to section 13.3.5, it has to assume that the IA is lost and that it needs to notify the application layer and to send a Request to reestablish an IA with B. The first REPLY is not necessarily the best. I can't find anything in the spec about this. Jerome Labussiere From owner-dhcp-v4@bucknell.edu Wed Mar 14 13:13:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00191 for ; Wed, 14 Mar 2001 13:13:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EI5WL25897; Wed, 14 Mar 2001 13:05:33 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EI5OL09587 for ; Wed, 14 Mar 2001 13:05:29 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 14 Mar 2001 10:56:32 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 10:56:35 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E806F2AEBC@zwdld001.ca.nortel.com> From: "Biswaroop Mukherjee" To: DHCPv4 discussion list Subject: RE: why authenticate with DHCP? Date: Wed, 14 Mar 2001 10:56:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC9F.56B11FC0" X-Orig: Reply-To: biswaroo@nortelnetworks.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_001_01C0AC9F.56B11FC0 Content-Type: text/plain; charset="ISO-8859-1" [Roop says] Aside from the discussion about 802 being the protocol of the future, I am trying to understand what is it that makes the link layer a better place for a AAA client. There seems to be some other opinion around like BURP proposal seems to see some value in doing it at the application level for already configured terminals. Elaboration is inline. > -----Original Message----- > From: Bernard D. Aboba [SMTP:aboba@internaut.com] > Sent: Friday, March 02, 2001 2:15 PM > To: DHCPv4 discussion list > Cc: DHCPv4 discussion list; Gage, Bill [WDLN2:AN00-M:EXCH]; > 'jschnizl@cisco.com'; 'bmukherj@styx.uwaterloo.ca' > Subject: RE: why authenticate with DHCP? > > > I would argue that in the wireless > > world, there is a lot of room for innovation...we are basically just > > starting... > > I was just curious to understand some of the logic that is driving the > evolution of wireless link layers. In many cases, wireless links do > indeed use PPP or 802 framing. Are there specific reasons why these > choices would not prove satisfactory in some cases? > [Roop says] Wireless networks are moving towards becoming all-IP above the link layer. The push there as I understand it is to restrict the link and physical layers to their original functions of getting the best (throughput, loss delay etc.) out of the radio channel. Ideally you would have almost wire like links with IP and all of its companion protocols running over them. Independence among layers and protocols is a crucial motivation. What this argues for is that things like spread spectrum security should be dealt with in lower layers but don't expect the lower layers to know about communicating keys for protocols that are several layers above and are not related to them. [Roop says] It seems that the point you make below is that changing AAA is cumbersome. Agreed: but I cannot see why the IP layer (DHCP etc.) will cause this. All that needs to be done is to generate the AAA messages in a language that an AAA server can presently understand and this is the responsibility of the AAA client. This client can reside in a DHCP box or the anywhere else according to the requirements of a given network. It will in turn extract the user credentials (again) in a way best suited to a given network. I do not see why putting it in link layer or higher will be an advantage. > > 2. A meta argument that follows, is that of service integration. How > would > > a service provider deploy a AAA system that works across all its Access > > Network offerings? > > It's very important to understand the AAA extensibility model, and why > we've had such trouble accomodating DHCP and MIP, while extension to new > link layers like VPN, ADSL, and 802 have been easy. > > AAA protocols support extensibility via addition of AVPs and attribute > values. > This is how RADIUS, which was created for dialup, has been able > to be used in ADSL, VPNs, 802, etc. without any changes to the protocol. > > However, in the process, the assumption is that the AAA server does not > actually need to add any code, only dictionary changes. This means that > the AAA server MUST NOT be required to understand any details of the > protocols that occur on the wire between the client and NAS. > > This critical assumption is broken if the AAA server is required to > understand a new PDU type (such as parsing a DHCP or MIP > registration message). This is why it is so hard for AAA to integrate > with protocols that utilize a Message Integrity Check (MIC) that > needs to be verified by AAA. The problem is that the AAA implementation > then needs to have a copy of the entire packet to verify the MIC -- which > requires the AAA server to parse the packet. This breaks the AAA > architectural model. > > > each link layer, even if it is 802 based, may interface with AAA in > slightly > > different way... > > One of the major design points of AAA is to be able to handle new link > layers with no changes to the protocol, only changes to the dictionary. > That way these new access methods can be accomodated without code > changes. Of the extensions, ADSL and 802 integration have been the most > successful -- being accomplished without requiring new AVPs, only new > attribute values. VPN integration was somewhat less successful, since > the "tags" required were not supported well on some implementations, > requiring dictionary code changes. But even there, no protocol changes > were required, and no adjustment to the AAA architectural model. > > > always cut it and thus break integration later on.... > > As described early, the only thing that can "break integration" is > changing the AAA architectural model, such as by requiring that it > integrate with other protocols, thereby requiring large implementation > changes. This is one of my issues with the DHCP/AAA integration proposal > -- it would require the AAA server to understand DHCP, in order to be > able to sign the authenticated DHCP packets. The alternative, which is to > use challenge/response authentication, does not satisfy the authenticated > DHCP security requirements since it would not integrity protect the > packet. > > > So, a network layer mechanism is always better or at least safer... > > Experience has told us that the biggest AAA integration problems actually > occur with network-layer authentication methods that require integrity > protection, such as authenticated DHCP and Mobile IP. Far from > being "safe", this kind of integration has proven to take years to work > through, changes in the fundamental AAA architecture, etc. Meanwhile, > changes for new link layers have been relatively trivial. > [Roop says] snip.. > Remember, IEEE 802 is not a single technology, it is a family of link > layers with considerable diversity. And "popular at the moment" seems to > imply that IEEE 802 technology is a passing fad, when in fact it seems > more likely that IEEE 802 will outlast IPv4. > [Roop says] It remains to be seen what protocol outlasts what in the future, and should not be the basis for selecting or rejecting mechanisms that can be of use the near term. ------_=_NextPart_001_01C0AC9F.56B11FC0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: why authenticate with DHCP?

[Roop = says]  Aside = from the discussion about 802 being the protocol of the future, I am = trying to understand what is it that makes the link layer a better = place for a AAA client. There seems to be some other opinion around = like BURP proposal seems to see some value in doing it at the = application level for already configured terminals. Elaboration is = inline.

-----Original Message-----
From:   Bernard D. Aboba = [SMTP:aboba@internaut.com]
Sent:   Friday, March 02, 2001 2:15 PM
To:     DHCPv4 discussion list
Cc:     DHCPv4 discussion list; Gage, Bill [WDLN2:AN00-M:EXCH]; = 'jschnizl@cisco.com'; 'bmukherj@styx.uwaterloo.ca'
Subject:       = RE: why authenticate with = DHCP?

> I would argue that in the = wireless
> world, there is a lot of room = for innovation...we are basically just
> starting...

I was just curious to understand some = of the logic that is driving the
evolution of wireless link layers. In = many cases, wireless links do
indeed use PPP or 802 framing. Are = there specific reasons why these
choices would not prove satisfactory = in some cases?

[Roop = says]  = Wireless networks are moving towards becoming all-IP above the link = layer. The push there as I understand it is to restrict the link and = physical layers to their original functions of getting the best = (throughput, loss delay etc.) out of the radio channel. Ideally you = would have almost wire like links with IP and all of its companion = protocols running over them. Independence among layers and protocols is = a crucial motivation. What this argues for is that things like spread = spectrum security should be dealt with in lower layers but don't expect = the lower layers to know about communicating keys for protocols that = are several layers above and are not related to them.

[Roop = says]  It = seems that the point you make below is that changing AAA is cumbersome. = Agreed: but I cannot see why the IP layer (DHCP etc.) will cause this. = All that needs to be done is to generate the AAA messages in a language = that an AAA server can presently understand and this is the = responsibility of the AAA client. This client can reside in a DHCP box = or the anywhere else according to the requirements of a given network. = It will in turn extract the user credentials (again) in a way best = suited to a given network. I do not see why putting it in link layer or = higher will be an advantage.

> 2.  A meta argument that = follows, is that of service integration. How would
> a service provider deploy a AAA = system that works across all its Access
> Network offerings?

It's very important to understand the = AAA extensibility model, and why
we've had such trouble accomodating = DHCP and MIP,  while extension to new
link layers like VPN, ADSL, and 802 = have been easy.

AAA protocols support extensibility = via addition of AVPs and attribute values.
This is how RADIUS, which was created = for dialup, has been able
to be used in ADSL, VPNs, 802, etc. = without any changes to the protocol.

However, in the process, the = assumption is that the AAA server does not
actually need to add any code, only = dictionary changes. This means that
the AAA server MUST NOT be required = to understand any details of the
protocols that occur on the wire = between the client and NAS.

This critical assumption is broken if = the AAA server is required to
understand a new PDU type (such as = parsing a DHCP or MIP
registration message). This is why it = is so hard for AAA to integrate
with protocols that utilize a Message = Integrity Check (MIC) that
needs to be verified by AAA. The = problem is that the AAA implementation
then needs to have a copy of the = entire packet to verify the MIC -- which
requires the AAA server to parse the = packet. This breaks the AAA
architectural model.

> each link layer, even if it is = 802 based, may interface with AAA in slightly
> different way...

One of the major design points of AAA = is to be able to handle new link
layers with no changes to the = protocol, only changes to the dictionary.
That way these new access methods can = be accomodated without code
changes. Of the extensions, ADSL and = 802 integration have been the most
successful -- being accomplished = without requiring new AVPs, only new
attribute values. VPN integration was = somewhat less successful, since
the "tags" required were = not supported well on some implementations,
requiring dictionary code changes. = But even there, no protocol changes
were required, and no adjustment to = the AAA architectural model. 

> always cut it and thus break = integration later on....

As described early, the only thing = that can "break integration" is
changing the AAA architectural model, = such as by requiring that it
integrate with other protocols, = thereby requiring large implementation
changes. This is one of my issues = with the DHCP/AAA integration proposal
-- it would require the AAA server to = understand DHCP, in order to be
able to sign the authenticated DHCP = packets. The alternative, which is to
use challenge/response = authentication, does not satisfy the authenticated
DHCP security requirements since it = would not integrity protect the
packet.

> So, a network layer mechanism is = always better or at least safer...

Experience has told us that the = biggest AAA integration problems actually
occur with network-layer = authentication methods that require integrity
protection, such as authenticated = DHCP and Mobile IP. Far from
being "safe", this kind of = integration has proven to take years to work
through, changes in the fundamental = AAA architecture, etc. Meanwhile,
changes for new link layers have been = relatively trivial.

[Roop = says]  = snip..

 Remember, IEEE 802 is not a = single technology, it is a family of link
layers with considerable diversity. = And "popular at the moment" seems to
imply that IEEE 802 technology is a = passing fad, when in fact it seems
more likely that IEEE 802  will = outlast IPv4.

[Roop = says]  It = remains to be seen what protocol outlasts what in the future, and = should not be the basis for selecting or rejecting mechanisms that can = be of use the near term.

------_=_NextPart_001_01C0AC9F.56B11FC0-- From owner-dhcp-v6@bucknell.edu Wed Mar 14 14:52:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02861; Wed, 14 Mar 2001 14:52:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EJnYL22006; Wed, 14 Mar 2001 14:49:34 -0500 (EST) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EJnUL11539 for ; Wed, 14 Mar 2001 14:49:30 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel1.hp.com (Postfix) with ESMTP id 55AB6357; Wed, 14 Mar 2001 14:49:22 -0500 (EST) Received: from india.hp.com (vijayak@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 BAA19617; Thu, 15 Mar 2001 01:17:09 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3AAFCBBF.E0F8D5A1@india.hp.com> Date: Thu, 15 Mar 2001 01:21:27 +0530 From: Vijay Bhaskar A K Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Cc: rdroms@cisco.com, DHCPv6 discussion list Subject: why seperate Ia is needed for sending new Requests? 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 Hi Jim and Ralph, I have issues to discuss in telecon. Why seperate IA is needed for sending new requests. It can be send in the same IA itself. This can be done very will the single IA. sume the IA has already 2 addresses. Now, the client wants another 3 addresses. For requesting another 3 addresses, send the same IA option with following. 1. make num-addrs field as 5. 2. Include already existing 2 addresses in the IA option with filled prefix length, IPv6 address and preferred lifetime and valid life time values. For the remaining 3 address newly asked, fill the prefix length, IPv6 address, pref-life time, valid-life time with zero and make the corresponding VB> addr status to ADDR_REQUEST indicating, the client is asking the address. This has some advantages also. 1. The DUID is need not to be generated for each and every request. 2. The server can maintain the list of IP-address it is managing for a particular interface of a node. This will minimize the number of records maintained. 3. If a client has sent 100 different requests, then it will have 100 IAs. Thus the server has to sent unicast Reconfigure-init message to the same client 100 times, since the server no way identify the different IAs belong to same client. Regards, Vijay -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ From owner-dhcp-v6@bucknell.edu Wed Mar 14 15:13:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03236; Wed, 14 Mar 2001 15:13:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EKDKL25082; Wed, 14 Mar 2001 15:13:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EKDBL04118 for ; Wed, 14 Mar 2001 15:13:11 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2EKD5i23945 for ; Wed, 14 Mar 2001 14:13:05 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2EKD5v18516 for ; Wed, 14 Mar 2001 14:13:05 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Mar 14 14:13:05 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 14:14:48 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB833@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Question about REBIND message Date: Wed, 14 Mar 2001 14:14:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ACC3.6973C990" 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 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_001_01C0ACC3.6973C990 Content-Type: text/plain; charset="iso-8859-1" I think that the server should be able to send back: - Success - No Binding - Bad prefixes (or some similar error status that means that the server is authoritative for the link and that the prefixes are invalid for that particular link) - Bad binding (or some similar error status that means that the address(es) are in use by another client) Ideally, the above could be on each individual address in an IA. What a client would do is wait until it got back some status. The meanings would be: - Success -> addresses are OK to use - No binding -> this server has no record of the bindings, but the PREFIXES are valid for the link - Bad prefixes -> the client is on a new link - Bad binding -> the client's addresses are bad (prefixes are OK, though that may be meaningless) If the client gets back Success, it can use the addresses. If the client gets back Bad Prefixes or Bad Binding, it needs to go to Solicit to find a server to get addresses. If the client gets back No Binding, it can use the addresses (unless it later receives a Bad Binding) - Bernie -----Original Message----- From: Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] Sent: Wednesday, March 14, 2001 12:07 PM To: DHCPv6 discussion list Subject: Re: Question about REBIND message Jim.Bound@nokia.com wrote: > > > -----Original Message----- > > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > > Sent: Wednesday,March 14,2001 9:49 AM > > To: DHCPv6 discussion list > > Subject: Question about REBIND message > > > > > > Hello > > > > In the -18 rev, it is said that the client send the REBIND > > message at T2 > > (section 16.2) to 'any available server' in order to extend the > > lifetimes of an IA, if the primary server has not responded at T1. I > > guess 'any available server' means any server which can receive the > > message (because it is onlink or via a relay). However, according to > > section 13.4.4 the server can successfully extend the > > lifetimes only if > > it has a binding for this client. > > thats correct. the idea is if another server thru some other means can do > this we don't want to prohibit the function for rebind. > > Assume a server with no binding returns an IA Empty/NoBinding REPLY > > message before a server with a binding. How should we handle this ? > > Should we wait for an other reply ? How much time ? Same thing for all > > messages with 0 in the server-adress field. > > the client should react immediately is my view. this is a case where we > don't want mobile nodes hanging out. clients can always do policing of > packets esp mobile nodes. > Ok, so the idea of REBIND is to try everything to keep a set of addresses. Still one dark point: About 'reacting immediately', I've the feeling that it works with one DHCP server in the domain. But with two ? For instance, if the client has a binding with server A. For a good reason, it has to send a CONFIRM message. Server A and server B receive the CONFIRM and answer. A returns a REPLY/status 0 and B returns a REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by the client and A's REPLY is received one or two ms after. If the client reacts immediately, according to section 13.3.5, it has to assume that the IA is lost and that it needs to notify the application layer and to send a Request to reestablish an IA with B. The first REPLY is not necessarily the best. I can't find anything in the spec about this. Jerome Labussiere ------_=_NextPart_001_01C0ACC3.6973C990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question about REBIND message

I think that the server should be able to send = back:
- Success
- No Binding
- Bad prefixes (or some similar error status that = means that the server is authoritative for the link and that the = prefixes are invalid for that particular link)

- Bad binding (or some similar error status that = means that the address(es) are in use by another client)

Ideally, the above could be on each individual = address in an IA.

What a client would do is wait until it got back some = status. The meanings would be:
- Success -> addresses are OK to use
- No binding -> this server has no record of the = bindings, but the PREFIXES are valid for the link
- Bad prefixes -> the client is on a new = link
- Bad binding -> the client's addresses are bad = (prefixes are OK, though that may be meaningless)

If the client gets back Success, it can use the = addresses.
If the client gets back Bad Prefixes or Bad Binding, = it needs to go to Solicit to find a server to get addresses.
If the client gets back No Binding, it can use the = addresses (unless it later receives a Bad Binding)

- Bernie

-----Original Message-----
From: Jerome Labussiere [mailto:Jerome.Labussiere@c= rm.mot.com]
Sent: Wednesday, March 14, 2001 12:07 PM
To: DHCPv6 discussion list
Subject: Re: Question about REBIND message


Jim.Bound@nokia.com wrote:
>
> > -----Original Message-----
> > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@c= rm.mot.com]
> > Sent: Wednesday,March 14,2001 9:49 = AM
> > To: DHCPv6 discussion list
> > Subject: Question about REBIND = message
> >
> >
> > Hello
> >
> > In the -18 rev, it is said that the client = send the REBIND
> > message at T2
> > (section 16.2) to 'any available server' = in order to extend the
> > lifetimes of an IA, if the primary server = has not responded at T1. I
> > guess 'any available server' means any = server which can receive the
> > message (because it is onlink or via a = relay). However, according to
> > section 13.4.4 the server can successfully = extend the
> > lifetimes only if
> > it has a binding for this client.
>
> thats correct. the idea is if another server = thru some other means can do
> this we don't want to prohibit the function for = rebind.
> > Assume a server with no binding returns an = IA Empty/NoBinding REPLY
> > message before a server with a binding. = How should we handle this ?
> > Should we wait for an other reply ? How = much time ? Same thing for all
> > messages with 0 in the server-adress = field.
>
> the client should react immediately is my = view.  this is a case where we
> don't want mobile nodes hanging out.  = clients can always do policing of
> packets esp mobile nodes.
>

Ok, so the idea of REBIND is to try everything to = keep a set of
addresses.

Still one dark point: About 'reacting immediately', = I've the feeling
that it works with one DHCP server in the domain. = But with two ? For
instance, if the client has a binding with server A. = For a good reason,
it has to send a CONFIRM message. Server A and = server B receive the
CONFIRM and answer. A returns a REPLY/status 0 and B = returns a
REPLY/Status NoBinding. Unfortunately, B's REPLY is = received first by
the client and A's REPLY is received one or two ms = after. If the client
reacts immediately, according to section 13.3.5, it = has to assume that
the IA is lost and that it needs to notify the = application layer and to
send a Request to reestablish an IA with B. The = first REPLY is not
necessarily the best. I can't find anything in the = spec about this.

Jerome Labussiere

------_=_NextPart_001_01C0ACC3.6973C990-- From owner-dhcp-v6@bucknell.edu Wed Mar 14 15:28:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03669; Wed, 14 Mar 2001 15:28:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EKQ1L17006; Wed, 14 Mar 2001 15:26:01 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EKPkL04878 for ; Wed, 14 Mar 2001 15:25:46 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2EKPgi05036 for ; Wed, 14 Mar 2001 14:25:42 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2EKPfv26792 for ; Wed, 14 Mar 2001 14:25:41 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Mar 14 14:25:35 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 14:27:18 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB834@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Reducing the DHCPv6 packet size? Date: Wed, 14 Mar 2001 14:27:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ACC5.29475790" 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 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_001_01C0ACC5.29475790 Content-Type: text/plain; charset="iso-8859-1" Jim ... see BV> below. However, you might want to first read this: I want to understand the fundamental reason why we have to put it in the DHCPv6 message itself? NOW, I will tell you WHY we *MUST* have it in there (based on today). My suggestion was based on the -18 draft where the client always sent packets to the link-local multicast address for the All DHCP Agents address. HOWEVER, if we allow the client to unicast (or even multicast to other than a link-local address), the client's IPv6 header (source address) CAN *NOT* CONTAIN A LINK-LAYER ADDRESS if the destination is not a LINK-LAYER-ADDRESS. So, if we change the DHCPv6 protocol (which we did discuss today in the conference call) to allowing the client to communicate directly with an off-link server, I *MUST* withdraw this. I should probably have made that clear in my original message (it assumed the -18 draft behavior). So, based on today's discussion and Design Team preference to change the client sending behavior, we can drop this request. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Wednesday, March 14, 2001 10:35 AM To: DHCPv6 discussion list Subject: RE: Reducing the DHCPv6 packet size? -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday,March 14,2001 9:38 AM To: DHCPv6 discussion list Subject: Reducing the DHCPv6 packet size? A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ... Do we really need to carry the client-link-local-address in most Client/Server interactions? [JPB2] I think absolutely. 1) The relay or server on the local link can simply use the source address of the packet. [JPB2] We were down this path. Doing this requires me to used the v6 advanced api or sysct or confget sys call . BV> No, recvfrom always returns the source address. So, you get it without doing anything special. What recvfrom does NOT return is the destination address for the datagram (and that is at least with IPv4 a pain to get). 2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet. [JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract. BV> Jim, it's already adding other stuff in forming the relay packet, this isn't a big deal (copy 16-bytes from the recvfrom source-address structure). 3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet. [JPB2] This adds new state to our new relay paradigm and more code as above. BV> No, it really doesn't. The server can simply get this out of the Relay-Forward packet it received. 4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum). [JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA. The link-local is inherent to IPv6 we must have it. BV> Yes, the addresses are in the *IP* packet header but they are not in the *TCP* and *UDP* packet header. This is exactly the same model I'm proposing. The client's link-layer address is already in the *IP* header. Why duplicate this in the datagram (you're just sending it twice in the packet). What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable. [JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol. also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units. BV> It isn't just for 3GPP - think of dial-up and other links that might use DHCP that have limited bandwidth capabilities. Great if compression is used; but you'll save more by not having it there in the first place. All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not). So, the proposed new headers would be: The DHCP message header: 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 | preference | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Relay-forward/Relay-reply message 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 | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | client-link-local-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | options (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Bernie Volz Ericsson [JPB2] I don't believe your arguments are strong enough to change the spec. There is a reason why we are here today. ------_=_NextPart_001_01C0ACC5.29475790 Content-Type: text/html; charset="iso-8859-1" Reducing the DHCPv6 packet size?
Jim ... see BV> below. However, you might want to first read this:
I want to understand the fundamental reason why we have to put it in the DHCPv6 message itself? NOW, I will tell you WHY we *MUST* have it in there (based on today). My suggestion was based on the -18 draft where the client always sent packets to the link-local multicast address for the All DHCP Agents address. HOWEVER, if we allow the client to unicast (or even multicast to other than a link-local address), the client's IPv6 header (source address) CAN *NOT* CONTAIN A LINK-LAYER ADDRESS if the destination is not a LINK-LAYER-ADDRESS. So, if we change the DHCPv6 protocol (which we did discuss today in the conference call) to allowing the client to communicate directly with an off-link server, I *MUST* withdraw this. I should probably have made that clear in my original message (it assumed the -18 draft behavior).
 
So, based on today's discussion and Design Team preference to change the client sending behavior, we can drop this request.
 
- Bernie
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Wednesday, March 14, 2001 10:35 AM
To: DHCPv6 discussion list
Subject: RE: Reducing the DHCPv6 packet size?

 
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday,March 14,2001 9:38 AM
To: DHCPv6 discussion list
Subject: Reducing the DHCPv6 packet size?

A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ...

Do we really need to carry the client-link-local-address in most Client/Server interactions?
[JPB2] I think absolutely.   

1) The relay or server on the local link can simply use the source address of the packet.
[JPB2] We were down this path.  Doing this requires me to used the v6 advanced api or sysct or confget sys call . 

BV> No, recvfrom always returns the source address. So, you get it without doing anything special. What recvfrom does NOT return is the destination address for the datagram (and that is at least with IPv4 a pain to get).

  
2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet.
[JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract.  

BV> Jim, it's already adding other stuff in forming the relay packet, this isn't a big deal (copy 16-bytes from the recvfrom source-address structure). 

3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet.
[JPB2] This adds new state to our new relay paradigm and more code as above.  

BV> No, it really doesn't. The server can simply get this out of the Relay-Forward packet it received. 

4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum).
[JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA.  The link-local is inherent to IPv6 we must have it.  

BV> Yes, the addresses are in the *IP* packet header but they are not in the *TCP* and *UDP* packet header. This is exactly the same model I'm proposing. The client's link-layer address is already in the *IP* header. Why duplicate this in the datagram (you're just sending it twice in the packet).

What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable.
[JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol.   also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units.  

BV> It isn't just for 3GPP - think of dial-up and other links that might use DHCP that have limited bandwidth capabilities. Great if compression is used; but you'll save more by not having it there in the first place. 

All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not).

So, the proposed new headers would be:


   The DHCP message header:

      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   |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Relay-forward/Relay-reply message

      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   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                   client-link-local-address                   |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Bernie Volz
  Ericsson
[JPB2] I don't believe your arguments are strong enough to change the spec.  There is a reason why we are here today.  

------_=_NextPart_001_01C0ACC5.29475790-- From owner-dhcp-v6@bucknell.edu Wed Mar 14 15:30:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03708; Wed, 14 Mar 2001 15:30:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2EKRuL23316; Wed, 14 Mar 2001 15:27:56 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2EKRpL21121 for ; Wed, 14 Mar 2001 15:27:51 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2EKRoi07032 for ; Wed, 14 Mar 2001 14:27:50 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2EKRov28077 for ; Wed, 14 Mar 2001 14:27:50 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Mar 14 14:27:41 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 14:29:24 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB835@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Wed, 14 Mar 2001 14:29:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ACC5.7548BD50" 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 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_001_01C0ACC5.7548BD50 Content-Type: text/plain; charset="iso-8859-1" The problem with is approach is that is requires the client to know how many addresses it wants. We don't want clients to have to know this. All they should do is request addresses - how many are returned is a server policy issue. - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, March 14, 2001 2:51 PM To: DHCPv6 discussion list Cc: rdroms@cisco.com; DHCPv6 discussion list Subject: why seperate Ia is needed for sending new Requests? Hi Jim and Ralph, I have issues to discuss in telecon. Why seperate IA is needed for sending new requests. It can be send in the same IA itself. This can be done very will the single IA. sume the IA has already 2 addresses. Now, the client wants another 3 addresses. For requesting another 3 addresses, send the same IA option with following. 1. make num-addrs field as 5. 2. Include already existing 2 addresses in the IA option with filled prefix length, IPv6 address and preferred lifetime and valid life time values. For the remaining 3 address newly asked, fill the prefix length, IPv6 address, pref-life time, valid-life time with zero and make the corresponding VB> addr status to ADDR_REQUEST indicating, the client is asking the address. This has some advantages also. 1. The DUID is need not to be generated for each and every request. 2. The server can maintain the list of IP-address it is managing for a particular interface of a node. This will minimize the number of records maintained. 3. If a client has sent 100 different requests, then it will have 100 IAs. Thus the server has to sent unicast Reconfigure-init message to the same client 100 times, since the server no way identify the different IAs belong to same client. Regards, Vijay -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C0ACC5.7548BD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?

The problem with is approach is that is requires the = client to know how many addresses it wants. We don't want clients to = have to know this. All they should do is request addresses - how many = are returned is a server policy issue.

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, March 14, 2001 2:51 PM
To: DHCPv6 discussion list
Cc: rdroms@cisco.com; DHCPv6 discussion list
Subject: why seperate Ia is needed for sending new = Requests?


Hi Jim and Ralph,

I have issues to discuss in telecon.
Why seperate IA is needed for sending new = requests.
It can be send in the same IA itself.
 This can be done very will the single IA. =
sume the IA has already 2 addresses. Now, the client = wants another
3 addresses. For requesting another 3 addresses, = send the same IA
option with following.
1. make num-addrs field as 5.
2. Include already existing 2 addresses in the IA = option with filled
prefix length, IPv6 address and preferred lifetime = and valid life time
values.
For the remaining 3 address newly asked, fill the = prefix length,
IPv6 address, pref-life time, valid-life time with = zero and make the
corresponding VB> addr status to ADDR_REQUEST = indicating, the client is
asking the address.

This has some advantages also.
1. The DUID is need not to be generated for each and = every request.
2. The server can maintain the list of IP-address it = is managing for
a particular interface of a node. This will minimize = the number of
records maintained.
3. If a client has sent 100 different requests, then = it will have 100
IAs. Thus the server has to sent unicast = Reconfigure-init message to the
same client 100 times, since the server no way = identify the different
IAs belong to same client.

Regards,
Vijay

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C0ACC5.7548BD50-- From owner-dhcp-v6@bucknell.edu Wed Mar 14 22:48:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11680; Wed, 14 Mar 2001 22:48:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2F3kJL22532; Wed, 14 Mar 2001 22:46:19 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2F3kHL06291 for ; Wed, 14 Mar 2001 22:46:17 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2F3llw13246 for ; Wed, 14 Mar 2001 21:47:57 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 21:45:56 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 21:45:55 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Reducing the DHCPv6 packet size? Date: Wed, 14 Mar 2001 21:45:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD02.6FD5DB40" 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 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_001_01C0AD02.6FD5DB40 Content-Type: text/plain; charset="iso-8859-1" Bernie, just as note rather than beating this dead horse. rcvfrom is not good enough for the relay. The relay needs to know what interface the packet came in on too. sendmsg with the v6 advanced api can do this was my point. but if we have to revisit this again I have other performance reasons. but will drop them for now. the relay could get then interface index too via the base api and then compare the address from dst addr which is possible. But the relay has to send the packet out the interface to the client on which it came from is where I was going. Your right I can always extract it from the header. But we were told to put the datums in the protocol whenever possible. I am not arguing how we get it. Just that I want it. On saving bytes. If that is our goal there are lots of places to do that. Not sure its our goal now? The reason I used 3gpp and not dial up lines et al. Is that the first deployment will be 3gpp and kind of on my mind as its a real IPv6 market I can taste which does bias my responses....I am also not against saving bytes. I am against changing our mind a lot at this point. We have a path. Lets follow it. If its bogus we will find out real quick. thanks /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday,March 14,2001 3:27 PM To: 'dhcp-v6@bucknell.edu'; 'jim.bound@nokia.com' Subject: RE: Reducing the DHCPv6 packet size? Jim ... see BV> below. However, you might want to first read this: I want to understand the fundamental reason why we have to put it in the DHCPv6 message itself? NOW, I will tell you WHY we *MUST* have it in there (based on today). My suggestion was based on the -18 draft where the client always sent packets to the link-local multicast address for the All DHCP Agents address. HOWEVER, if we allow the client to unicast (or even multicast to other than a link-local address), the client's IPv6 header (source address) CAN *NOT* CONTAIN A LINK-LAYER ADDRESS if the destination is not a LINK-LAYER-ADDRESS. So, if we change the DHCPv6 protocol (which we did discuss today in the conference call) to allowing the client to communicate directly with an off-link server, I *MUST* withdraw this. I should probably have made that clear in my original message (it assumed the -18 draft behavior). So, based on today's discussion and Design Team preference to change the client sending behavior, we can drop this request. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Wednesday, March 14, 2001 10:35 AM To: DHCPv6 discussion list Subject: RE: Reducing the DHCPv6 packet size? -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday,March 14,2001 9:38 AM To: DHCPv6 discussion list Subject: Reducing the DHCPv6 packet size? A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ... Do we really need to carry the client-link-local-address in most Client/Server interactions? [JPB2] I think absolutely. 1) The relay or server on the local link can simply use the source address of the packet. [JPB2] We were down this path. Doing this requires me to used the v6 advanced api or sysct or confget sys call . BV> No, recvfrom always returns the source address. So, you get it without doing anything special. What recvfrom does NOT return is the destination address for the datagram (and that is at least with IPv4 a pain to get). 2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet. [JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract. BV> Jim, it's already adding other stuff in forming the relay packet, this isn't a big deal (copy 16-bytes from the recvfrom source-address structure). 3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet. [JPB2] This adds new state to our new relay paradigm and more code as above. BV> No, it really doesn't. The server can simply get this out of the Relay-Forward packet it received. 4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum). [JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA. The link-local is inherent to IPv6 we must have it. BV> Yes, the addresses are in the *IP* packet header but they are not in the *TCP* and *UDP* packet header. This is exactly the same model I'm proposing. The client's link-layer address is already in the *IP* header. Why duplicate this in the datagram (you're just sending it twice in the packet). What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable. [JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol. also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units. BV> It isn't just for 3GPP - think of dial-up and other links that might use DHCP that have limited bandwidth capabilities. Great if compression is used; but you'll save more by not having it there in the first place. All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not). So, the proposed new headers would be: The DHCP message header: 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 | preference | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Relay-forward/Relay-reply message 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 | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | client-link-local-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | options (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Bernie Volz Ericsson [JPB2] I don't believe your arguments are strong enough to change the spec. There is a reason why we are here today. ------_=_NextPart_001_01C0AD02.6FD5DB40 Content-Type: text/html; charset="iso-8859-1" Reducing the DHCPv6 packet size?
Bernie,
 
just as note rather than beating this dead horse.  rcvfrom is not good enough for the relay.  The relay needs to know what interface the packet came in on too.  sendmsg with the v6 advanced api can do this was my point.  but if we have to revisit this again I have other performance reasons.  but will drop them for now.  the relay could get then interface index too via the base api and then compare the address from dst addr which is possible.  But the relay has to send the packet out the interface to the client on which it came from is where I was going.
 
Your right I can always extract it from the header.  But we were told to put the datums in the protocol whenever possible.  I am not arguing how we get it.  Just that I want it.
 
On saving bytes.  If that is our goal there are lots of places to do that.  Not sure its our goal now?
The reason I used 3gpp and not dial up lines et al.  Is that the first deployment will be 3gpp and kind of on my mind as its  a real IPv6 market I can taste which does bias my responses....I am also not against saving bytes.  I am against changing our mind a lot at this point.  We have a path.  Lets follow it. If its bogus we will find out real quick.
 
thanks
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday,March 14,2001 3:27 PM
To: 'dhcp-v6@bucknell.edu'; 'jim.bound@nokia.com'
Subject: RE: Reducing the DHCPv6 packet size?

Jim ... see BV> below. However, you might want to first read this:
I want to understand the fundamental reason why we have to put it in the DHCPv6 message itself? NOW, I will tell you WHY we *MUST* have it in there (based on today). My suggestion was based on the -18 draft where the client always sent packets to the link-local multicast address for the All DHCP Agents address. HOWEVER, if we allow the client to unicast (or even multicast to other than a link-local address), the client's IPv6 header (source address) CAN *NOT* CONTAIN A LINK-LAYER ADDRESS if the destination is not a LINK-LAYER-ADDRESS. So, if we change the DHCPv6 protocol (which we did discuss today in the conference call) to allowing the client to communicate directly with an off-link server, I *MUST* withdraw this. I should probably have made that clear in my original message (it assumed the -18 draft behavior).
 
So, based on today's discussion and Design Team preference to change the client sending behavior, we can drop this request.
 
- Bernie
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Wednesday, March 14, 2001 10:35 AM
To: DHCPv6 discussion list
Subject: RE: Reducing the DHCPv6 packet size?

 
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday,March 14,2001 9:38 AM
To: DHCPv6 discussion list
Subject: Reducing the DHCPv6 packet size?

A question/suggestion about reducing the DHCPv6 packet size (by 16 bytes) ...

Do we really need to carry the client-link-local-address in most Client/Server interactions?
[JPB2] I think absolutely.   

1) The relay or server on the local link can simply use the source address of the packet.
[JPB2] We were down this path.  Doing this requires me to used the v6 advanced api or sysct or confget sys call . 

BV> No, recvfrom always returns the source address. So, you get it without doing anything special. What recvfrom does NOT return is the destination address for the datagram (and that is at least with IPv4 a pain to get).

  
2) A relay will need to include the client-link-local-address when it sends a Relay-Forward to a server, but that can be added into the relay's packet.
[JPB2] we want to reduce the execution of code path on relays when ever possible. mv or copy is faster than read header and extract.  

BV> Jim, it's already adding other stuff in forming the relay packet, this isn't a big deal (copy 16-bytes from the recvfrom source-address structure). 

3) A server will need to include the client-link-local-address when it sends a Relay-Reply to a server, but that again can be added into the relay's packet.
[JPB2] This adds new state to our new relay paradigm and more code as above.  

BV> No, it really doesn't. The server can simply get this out of the Relay-Forward packet it received. 

4) If authentication (of whatever type) wants to cover the client-link-local-address, that can be added to some pseudo-header (much like TCP and UDP have the source and destination address in the pseudo-header when they calculate the checksum).
[JPB2] exactly and like tcp and udp the addresses are in the packet data not the header on any psuedo checksum I have worked on v4 or v6 and old DECnet and SNA.  The link-local is inherent to IPv6 we must have it.  

BV> Yes, the addresses are in the *IP* packet header but they are not in the *TCP* and *UDP* packet header. This is exactly the same model I'm proposing. The client's link-layer address is already in the *IP* header. Why duplicate this in the datagram (you're just sending it twice in the packet).

What this means is that client <--> agent interactions would save 16 bytes/packet and the Relay <--> server interaction packets would be the same size. For 3GPP/UMTS networks, this would save bytes over the air interface which is desireable.
[JPB2] Well if start trying to save bytes for 3gpp we then go back to the original dhcpv6 msg formats and I think we decided that dhcp is a control protocol.   also compression will be used in 3gpp at the radio, relay, sgsn, and ggsn interface logical units.  

BV> It isn't just for 3GPP - think of dial-up and other links that might use DHCP that have limited bandwidth capabilities. Great if compression is used; but you'll save more by not having it there in the first place. 

All IP stacks (whether IPv4 or IPv6) must always provide the SOURCE address of a packet on a receive operation (such as socket's recvfrom). And, I can't imagine that the address selection logic for IPv6 would ever suggest using a non-link-local address for the IPv6 header source address if the destination address is a link-local-address (whether multicast or not).

So, the proposed new headers would be:


   The DHCP message header:

      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   |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Relay-forward/Relay-reply message

      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   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                   client-link-local-address                   |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Bernie Volz
  Ericsson
[JPB2] I don't believe your arguments are strong enough to change the spec.  There is a reason why we are here today.  

------_=_NextPart_001_01C0AD02.6FD5DB40-- From owner-dhcp-v4@bucknell.edu Thu Mar 15 06:44:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28378 for ; Thu, 15 Mar 2001 06:44:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FBbUL11231; Thu, 15 Mar 2001 06:37:31 -0500 (EST) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FBbOL21811 for ; Thu, 15 Mar 2001 06:37:24 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Thu, 15 Mar 2001 11:36:08 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 11:36:06 -0000 Message-ID: <588B15E2E2B1D41180B800508BF934F251E6ED@bmdhd6.europe.nortel.com> From: "William Parton" To: DHCPv4 discussion list Subject: Multiple IP address allocations Date: Thu, 15 Mar 2001 11:36:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD44.1E442E20" Reply-To: parton@nortelnetworks.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_001_01C0AD44.1E442E20 Content-Type: text/plain; charset="iso-8859-1" I am looking at an application that requires multiple IP addresses to be allocated to a single device. There is an additional complication that there is a relationship between the multiple addresses (in this case four contiguous IP addresses must be allocated to a single device). I see from the DHCP FAQ that a typical DHCP server implementation should: "Allow manual allocation of two or more alternative IP numbers to a single MAC address, whose use depends upon the gateway address through which the request is relayed." This appears to be along the lines of what I'm looking for (except that all four requests would come via the same gateway address) and hints that multiple address allocation for a single device may have been addressed in this forum. There would seem to be two ways of achieving multiple IP address allocations: - multiple DHCPDISCOVER requests, with the DHCP server being configured to allocate IP addresses to the device taking into account any relationships between the IP addresses. This may mandate the use of static IP address allocation. - or a single DHCPDISCOVER/DHCPOFFER pair, but have multiple IP addresses allocated within the DHCPOFFER (using a suitable vendor extension). The first option would appear to be more in keeping with the DHCP architecture but requires additional controls and management within the DHCP server. Has such an requirement been previously addressed? I have not been able to find any relevant information in the FAQ or DHCP-v4 archives. regards Will ------_=_NextPart_001_01C0AD44.1E442E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Multiple IP address allocations

I am looking at an application that requires multiple = IP addresses to be allocated to a single device. There is an additional = complication that there is a relationship between the multiple = addresses (in this case four contiguous IP addresses must be allocated = to a single device).

I see from the DHCP FAQ that a typical DHCP server = implementation should:
"Allow manual allocation of two or more = alternative IP numbers to a single MAC address, whose use depends upon = the gateway address through which the request is relayed." This = appears to be along the lines of what I'm looking for (except that all = four requests would come via the same gateway address) and hints that = multiple address allocation for a single device may have been addressed = in this forum.

There would seem to be two ways of achieving multiple = IP address allocations:
- multiple DHCPDISCOVER requests, with the DHCP = server being configured to allocate IP addresses to the device taking = into account any relationships between the IP addresses. This may = mandate the use of static IP address allocation.

- or a single DHCPDISCOVER/DHCPOFFER pair, but have = multiple IP addresses allocated within the DHCPOFFER (using a suitable = vendor extension). 

The first option would appear to be more in keeping = with the DHCP architecture but requires additional controls and = management within the DHCP server.

Has such an requirement been previously addressed? I = have not been able to find any relevant information in the FAQ or = DHCP-v4 archives.

regards

Will

------_=_NextPart_001_01C0AD44.1E442E20-- From owner-dhcp-v6@bucknell.edu Thu Mar 15 07:00:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28529; Thu, 15 Mar 2001 07:00:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FBxcL30758; Thu, 15 Mar 2001 06:59:38 -0500 (EST) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FBxPL21562 for ; Thu, 15 Mar 2001 06:59:25 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel2.hp.com (Postfix) with ESMTP id 3A7337D6 for ; Thu, 15 Mar 2001 06:59:23 -0500 (EST) Received: from india.hp.com (vijayak@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 RAA12956 for ; Thu, 15 Mar 2001 17:27:12 +0530 (IST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3AB0AF1C.9E7542DF@india.hp.com> Date: Thu, 15 Mar 2001 17:31:32 +0530 From: Vijay Bhaskar A K Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? References: <66F66129A77AD411B76200508B65AC694CB835@eambunt705.ena-east.ericsson.se> 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 so, the client won't ask that it wants "n" number of address. It will just send a blank request. The server will allocate the number of addresses according to its policy. In case, if the client needs some 10 addresses. If the server's policy is to allocate one IP-address per request, then, the client has to send 10 requests instead of asking a request of 10 IP-address. Isn't it? Is there any specific reason for bringing the control to the number of addresses allocated to the server from the client. Actually, the client has to ask for this much number of address and the server has to allocate it, if it is able to do so. I this is the correct approach. -Vijay > "Bernie Volz (EUD)" wrote: > > The problem with is approach is that is requires the client to know > how many addresses it wants. We don't want clients to have to know > this. All they should do is request addresses - how many are returned > is a server policy issue. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, March 14, 2001 2:51 PM > To: DHCPv6 discussion list > Cc: rdroms@cisco.com; DHCPv6 discussion list > Subject: why seperate Ia is needed for sending new Requests? > > Hi Jim and Ralph, > > I have issues to discuss in telecon. > Why seperate IA is needed for sending new requests. > It can be send in the same IA itself. > This can be done very will the single IA. > sume the IA has already 2 addresses. Now, the client wants another > 3 addresses. For requesting another 3 addresses, send the same IA > option with following. > 1. make num-addrs field as 5. > 2. Include already existing 2 addresses in the IA option with filled > prefix length, IPv6 address and preferred lifetime and valid life time > > values. > For the remaining 3 address newly asked, fill the prefix length, > IPv6 address, pref-life time, valid-life time with zero and make the > corresponding VB> addr status to ADDR_REQUEST indicating, the client > is > asking the address. > > This has some advantages also. > 1. The DUID is need not to be generated for each and every request. > 2. The server can maintain the list of IP-address it is managing for > a particular interface of a node. This will minimize the number of > records maintained. > 3. If a client has sent 100 different requests, then it will have 100 > IAs. Thus the server has to sent unicast Reconfigure-init message to > the > same client 100 times, since the server no way identify the different > IAs belong to same client. > > Regards, > Vijay > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ From owner-dhcp-v6@bucknell.edu Thu Mar 15 08:21:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28932; Thu, 15 Mar 2001 08:21:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FDFcL02632; Thu, 15 Mar 2001 08:15:38 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FDFQL26489 for ; Thu, 15 Mar 2001 08:15:26 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2FDFOi19574 for ; Thu, 15 Mar 2001 07:15:25 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2FDFOL10878 for ; Thu, 15 Mar 2001 07:15:24 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 15 07:15:24 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 07:17:08 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB840@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Thu, 15 Mar 2001 07:17:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD52.3A9C76F0" 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 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_001_01C0AD52.3A9C76F0 Content-Type: text/plain; charset="iso-8859-1" Vijay: Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on. Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests. Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior? - Bernie Volz -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Thursday, March 15, 2001 7:02 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? so, the client won't ask that it wants "n" number of address. It will just send a blank request. The server will allocate the number of addresses according to its policy. In case, if the client needs some 10 addresses. If the server's policy is to allocate one IP-address per request, then, the client has to send 10 requests instead of asking a request of 10 IP-address. Isn't it? Is there any specific reason for bringing the control to the number of addresses allocated to the server from the client. Actually, the client has to ask for this much number of address and the server has to allocate it, if it is able to do so. I this is the correct approach. -Vijay > "Bernie Volz (EUD)" wrote: > > The problem with is approach is that is requires the client to know > how many addresses it wants. We don't want clients to have to know > this. All they should do is request addresses - how many are returned > is a server policy issue. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, March 14, 2001 2:51 PM > To: DHCPv6 discussion list > Cc: rdroms@cisco.com; DHCPv6 discussion list > Subject: why seperate Ia is needed for sending new Requests? > > Hi Jim and Ralph, > > I have issues to discuss in telecon. > Why seperate IA is needed for sending new requests. > It can be send in the same IA itself. > This can be done very will the single IA. > sume the IA has already 2 addresses. Now, the client wants another > 3 addresses. For requesting another 3 addresses, send the same IA > option with following. > 1. make num-addrs field as 5. > 2. Include already existing 2 addresses in the IA option with filled > prefix length, IPv6 address and preferred lifetime and valid life time > > values. > For the remaining 3 address newly asked, fill the prefix length, > IPv6 address, pref-life time, valid-life time with zero and make the > corresponding VB> addr status to ADDR_REQUEST indicating, the client > is > asking the address. > > This has some advantages also. > 1. The DUID is need not to be generated for each and every request. > 2. The server can maintain the list of IP-address it is managing for > a particular interface of a node. This will minimize the number of > records maintained. > 3. If a client has sent 100 different requests, then it will have 100 > IAs. Thus the server has to sent unicast Reconfigure-init message to > the > same client 100 times, since the server no way identify the different > IAs belong to same client. > > Regards, > Vijay > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C0AD52.3A9C76F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?

Vijay:

Any design has trade offs. If a client were to ask = for 5 addresses, what does that mean? Does it mean 5 addresses on a = single prefix or on 5 different prefixes? Networks might have multiple = prefixes active at one time, so asking for "n" addresses = isn't all you'd have to do - the client would have to say give me = "m" on prefix a, "o" on prefix b, and so = on.

Normally clients will only ask for their 'normal' = addressess. If they later need additional addresses (such as temporary = ones), they can do additional requests.

Do you really expect a client to want to ask for many = sets of addresses? If one excludes the temporary address issue, do you = see a client ever asking for more 'normal' addresses? Yes, we have the = mechanism by using the IA option, but is that likely to be the normal = behavior?

- Bernie Volz

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, March 15, 2001 7:02 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending = new Requests?


so, the client won't ask that it wants "n" = number of address. It will
just send a blank request. The server will allocate = the number of
addresses according to its policy. In case, if the = client needs some 10
addresses. If the server's policy is to allocate one = IP-address per
request, then, the client has to send 10 requests = instead of asking a
request of 10 IP-address. Isn't it?
Is there any specific reason for bringing the = control to the number of
addresses allocated to the server from the client. = Actually, the client
has to ask for this much number of address and the = server has to
allocate it, if it is able to do so. I this is the = correct approach.

-Vijay
> "Bernie Volz (EUD)" wrote:
>
> The problem with is approach is that is = requires the client to know
> how many addresses it wants. We don't want = clients to have to know
> this. All they should do is request addresses - = how many are returned
> is a server policy issue.
>
> - Bernie
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, March 14, 2001 2:51 PM
> To: DHCPv6 discussion list
> Cc: rdroms@cisco.com; DHCPv6 discussion = list
> Subject: why seperate Ia is needed for sending = new Requests?
>
> Hi Jim and Ralph,
>
> I have issues to discuss in telecon.
> Why seperate IA is needed for sending new = requests.
> It can be send in the same IA itself.
>  This can be done very will the single = IA.
> sume the IA has already 2 addresses. Now, the = client wants another
> 3 addresses. For requesting another 3 = addresses, send the same IA
> option with following.
> 1. make num-addrs field as 5.
> 2. Include already existing 2 addresses in the = IA option with filled
> prefix length, IPv6 address and preferred = lifetime and valid life time
>
> values.
> For the remaining 3 address newly asked, fill = the prefix length,
> IPv6 address, pref-life time, valid-life time = with zero and make the
> corresponding VB> addr status to = ADDR_REQUEST indicating, the client
> is
> asking the address.
>
> This has some advantages also.
> 1. The DUID is need not to be generated for = each and every request.
> 2. The server can maintain the list of = IP-address it is managing for
> a particular interface of a node. This will = minimize the number of
> records maintained.
> 3. If a client has sent 100 different requests, = then it will have 100
> IAs. Thus the server has to sent unicast = Reconfigure-init message to
> the
> same client 100 times, since the server no way = identify the different
> IAs belong to same client.
>
> Regards,
> Vijay
>
> --
> ____Vijay_Bhaskar_A_K____
> ______Inet_Services______
> ________HP_ISO___________
> ____Ph:_2251554_1424_____
> ___Pager:_9624_371137____

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C0AD52.3A9C76F0-- From owner-dhcp-v6@bucknell.edu Thu Mar 15 10:34:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01309; Thu, 15 Mar 2001 10:34:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FFV4L20888; Thu, 15 Mar 2001 10:31:04 -0500 (EST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FFUvL09260 for ; Thu, 15 Mar 2001 10:30:57 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Mar 2001 07:31:29 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 07:31:32 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 15 Mar 2001 07:31:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4663.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD65.02E1A222" Subject: RE: why seperate Ia is needed for sending new Requests? Date: Thu, 15 Mar 2001 07:31:31 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A681B6605@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: why seperate Ia is needed for sending new Requests? Thread-Index: AcCtUjZQmeJzMHJ2T5OID40pSC/PXwAELz0w From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 15 Mar 2001 15:31:32.0140 (UTC) FILETIME=[03153EC0:01C0AD65] 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0AD65.02E1A222 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service. =20 It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses.=20 =20 In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future. =20 thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 15, 2001 5:17 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Vijay:=20 Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on. Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests. Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior? - Bernie Volz=20 -----Original Message-----=20 From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com]=20 Sent: Thursday, March 15, 2001 7:02 AM=20 To: DHCPv6 discussion list=20 Subject: Re: why seperate Ia is needed for sending new Requests?=20 so, the client won't ask that it wants "n" number of address. It will=20 just send a blank request. The server will allocate the number of=20 addresses according to its policy. In case, if the client needs some 10=20 addresses. If the server's policy is to allocate one IP-address per=20 request, then, the client has to send 10 requests instead of asking a=20 request of 10 IP-address. Isn't it?=20 Is there any specific reason for bringing the control to the number of=20 addresses allocated to the server from the client. Actually, the client=20 has to ask for this much number of address and the server has to=20 allocate it, if it is able to do so. I this is the correct approach.=20 -Vijay=20 > "Bernie Volz (EUD)" wrote:=20 >=20 > The problem with is approach is that is requires the client to know=20 > how many addresses it wants. We don't want clients to have to know=20 > this. All they should do is request addresses - how many are returned=20 > is a server policy issue.=20 >=20 > - Bernie=20 >=20 > -----Original Message-----=20 > From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com]=20 > Sent: Wednesday, March 14, 2001 2:51 PM=20 > To: DHCPv6 discussion list=20 > Cc: rdroms@cisco.com; DHCPv6 discussion list=20 > Subject: why seperate Ia is needed for sending new Requests?=20 >=20 > Hi Jim and Ralph,=20 >=20 > I have issues to discuss in telecon.=20 > Why seperate IA is needed for sending new requests.=20 > It can be send in the same IA itself.=20 > This can be done very will the single IA.=20 > sume the IA has already 2 addresses. Now, the client wants another=20 > 3 addresses. For requesting another 3 addresses, send the same IA=20 > option with following.=20 > 1. make num-addrs field as 5.=20 > 2. Include already existing 2 addresses in the IA option with filled=20 > prefix length, IPv6 address and preferred lifetime and valid life time >=20 > values.=20 > For the remaining 3 address newly asked, fill the prefix length,=20 > IPv6 address, pref-life time, valid-life time with zero and make the=20 > corresponding VB> addr status to ADDR_REQUEST indicating, the client=20 > is=20 > asking the address.=20 >=20 > This has some advantages also.=20 > 1. The DUID is need not to be generated for each and every request.=20 > 2. The server can maintain the list of IP-address it is managing for=20 > a particular interface of a node. This will minimize the number of=20 > records maintained.=20 > 3. If a client has sent 100 different requests, then it will have 100=20 > IAs. Thus the server has to sent unicast Reconfigure-init message to=20 > the=20 > same client 100 times, since the server no way identify the different=20 > IAs belong to same client.=20 >=20 > Regards,=20 > Vijay=20 >=20 > --=20 > ____Vijay_Bhaskar_A_K____=20 > ______Inet_Services______=20 > ________HP_ISO___________=20 > ____Ph:_2251554_1424_____=20 > ___Pager:_9624_371137____=20 --=20 ____Vijay_Bhaskar_A_K____=20 ______Inet_Services______=20 ________HP_ISO___________=20 ____Ph:_2251554_1424_____=20 ___Pager:_9624_371137____=20 ------_=_NextPart_001_01C0AD65.02E1A222 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?
It is=20 entirely possible for a client to ask for more "normal" addresses. The = reason=20 being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A = server=20 that does web hosting may need thousands of IP addresses and it may not = be=20 possible to know the requirement ahead of time in all cases. It will = contact the=20 DHCP Server to request more IP addresses in this case or use stateless = config to=20 generate the IPs it needs. A server hosting different services may want = to use=20 different "normal" addresses for each service.
 
It is=20 also possible for the client to use different IP addresses for different = browser=20 sessions. In this case, the client may request temporary addresses. =
 
In any=20 case, it is likely that the DHCP client will have to generate IP = addresses on=20 the fly using stateless/stateful configs. In other words, the dhcpv6 = spec=20 shouldnt exclude this scenario as it is difficult to predict the=20 future.
 
thx
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, March = 15, 2001=20 5:17 AM
To: DHCPv6 discussion list
Subject: RE: = why=20 seperate Ia is needed for sending new Requests?

Vijay:

Any design has trade offs. If a client were to ask = for 5=20 addresses, what does that mean? Does it mean 5 addresses on a single = prefix or=20 on 5 different prefixes? Networks might have multiple prefixes active = at one=20 time, so asking for "n" addresses isn't all you'd have to do - the = client=20 would have to say give me "m" on prefix a, "o" on prefix b, and so=20 on.

Normally clients will only ask for their 'normal' = addressess.=20 If they later need additional addresses (such as temporary ones), they = can do=20 additional requests.

Do you really expect a client to want to ask for = many sets of=20 addresses? If one excludes the temporary address issue, do you see a = client=20 ever asking for more 'normal' addresses? Yes, we have the mechanism by = using=20 the IA option, but is that likely to be the normal = behavior?

- Bernie Volz

-----Original Message-----
From: Vijay=20 Bhaskar A K [mailto:vijayak@india.hp.com]=20
Sent: Thursday, March 15, 2001 7:02 AM =
To: DHCPv6 discussion list
Subject: = Re: why=20 seperate Ia is needed for sending new Requests?


so, the client won't ask that it wants "n" number of = address.=20 It will
just send a blank request. The = server will=20 allocate the number of
addresses according = to its=20 policy. In case, if the client needs some 10
addresses. If the server's policy is to allocate one = IP-address=20 per
request, then, the client has to send 10 = requests=20 instead of asking a
request of 10 = IP-address. Isn't=20 it?
Is there any specific reason for = bringing the=20 control to the number of
addresses allocated = to the=20 server from the client. Actually, the client
has to=20 ask for this much number of address and the server has to =
allocate it, if it is able to do so. I this is the correct=20 approach.

-Vijay
> "Bernie Volz = (EUD)"=20 wrote:
>
> = The problem=20 with is approach is that is requires the client to know =
> how many addresses it wants. We don't want clients to = have to=20 know
> this. All they should do is = request=20 addresses - how many are returned
> is a = server=20 policy issue.
>
> -=20 Bernie
>
> = -----Original=20 Message-----
> From: Vijay Bhaskar A K = [mailto:vijayak@india.hp.com]=20
> Sent: Wednesday, March 14, 2001 2:51 PM =
> To: DHCPv6 discussion list
> Cc:=20 rdroms@cisco.com; DHCPv6 discussion list
> Subject:=20 why seperate Ia is needed for sending new Requests?
>
> Hi Jim and Ralph, =
>
> I have issues to discuss = in=20 telecon.
> Why seperate IA is needed for = sending=20 new requests.
> It can be send in the = same IA=20 itself.
>  This can be done very = will the=20 single IA.
> sume the IA has already 2 = addresses.=20 Now, the client wants another
> 3 = addresses. For=20 requesting another 3 addresses, send the same IA
>=20 option with following.
> 1. make = num-addrs field as=20 5.
> 2. Include already existing 2 = addresses in the=20 IA option with filled
> prefix length, = IPv6 address=20 and preferred lifetime and valid life time
>=20
> values.
> = For the=20 remaining 3 address newly asked, fill the prefix length, =
> IPv6 address, pref-life time, valid-life time with zero = and make=20 the
> corresponding VB> addr status to = ADDR_REQUEST indicating, the client
> = is=20
> asking the address.
>=20
> This has some advantages also. =
> 1. The DUID is need not to be generated for each and = every=20 request.
> 2. The server can maintain the = list of=20 IP-address it is managing for
> a = particular=20 interface of a node. This will minimize the number of
> records maintained.
> 3. If = a client=20 has sent 100 different requests, then it will have 100 =
> IAs. Thus the server has to sent unicast = Reconfigure-init message=20 to
> the
> = same client=20 100 times, since the server no way identify the different =
> IAs belong to same client.
>=20
> Regards,
> = Vijay
>
> = --=20
> ____Vijay_Bhaskar_A_K____
>=20 ______Inet_Services______
>=20 ________HP_ISO___________
>=20 ____Ph:_2251554_1424_____
>=20 ___Pager:_9624_371137____

--
____Vijay_Bhaskar_A_K____=20
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____ =

------_=_NextPart_001_01C0AD65.02E1A222-- From owner-dhcp-v6@bucknell.edu Thu Mar 15 11:44:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02804; Thu, 15 Mar 2001 11:44:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FGeUL14255; Thu, 15 Mar 2001 11:40:30 -0500 (EST) 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 f2FGeLL31084 for ; Thu, 15 Mar 2001 11:40:22 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.124.31]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2D4LGg23891 for ; Mon, 12 Mar 2001 20:21:16 -0800 (PST) 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 f2FGdWk09948 for ; Thu, 15 Mar 2001 08:39:32 -0800 (PST) Message-Id: <200103151639.f2FGdWk09948@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? In-Reply-To: Message from "Thirumalesh Bhat" of "Thu, 15 Mar 2001 07:31:31 PST." <78B1387745A15C46A7A727F2670D4A681B6605@DF-MILO.platinum.corp.microsoft.com> Date: Thu, 15 Mar 2001 08:39:32 -0800 From: Ted Lemon 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 case, it is likely that the DHCP client will have to generate IP > addresses on the fly using stateless/stateful configs. In other words, > the dhcpv6 spec shouldnt exclude this scenario as it is difficult to > predict the future. The current spec, as far as I can tell (and I am also quite interested in this), supports this scenario. I'm not convinced it's likely, but it is supported. You do it with multiple IAs. We were originally going to do it the way you're proposing, and it turned out that that was actually a _lot_ more complicated, because we had no key<->address set relationship. I say "address set" rather than "address" because even a very simple individual client that needs only one way of being contacted may still be assigned more than one address by the server. This is because the address the client has been using may be deprecated during a renumbering event, for example. In this case, the client will be given its old address, which is deprecated, along with a new address, which is be preferred for starting new network connections. Because we can't depend on there being a single address for a given client even under the most simple circumstances, we can't use the client's assigned address as an identifier. That's why we're now solving the problem with one logical identifier per address set rather than one logical identifier per client. The identity association is the tuple of (logical identifier, address set, ...), and the server can use the logical identifier as a key to look up this identity association. We will still have a unique per-client identifier. The IA identifier will be a single logical identifier per IA that is constructed in a well-defined way using the per-client identifier and a per-IA index. Do you think that this isn't going to work at all, or did we just not explain ourselves well enough, or is it just not the solution that you'd prefer? _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Mar 15 12:02:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03236; Thu, 15 Mar 2001 12:02:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FH25L19909; Thu, 15 Mar 2001 12:02:05 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FH1oL22947 for ; Thu, 15 Mar 2001 12:01:50 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2FH1Ug21573 for ; Thu, 15 Mar 2001 11:01:40 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 15 Mar 2001 11:00:54 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 15 Mar 2001 11:00:54 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Question about REBIND message Date: Thu, 15 Mar 2001 11:00:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Jerome, Good catch. We should all discuss if we need a REBIND_TIME_XXX value before the client does new Request. Would that address this in your mind. thanks and again good catch, /jim > -----Original Message----- > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > Sent: Wednesday,March 14,2001 12:07 PM > To: DHCPv6 discussion list > Subject: Re: Question about REBIND message > > > Jim.Bound@nokia.com wrote: > > > > > -----Original Message----- > > > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > > > Sent: Wednesday,March 14,2001 9:49 AM > > > To: DHCPv6 discussion list > > > Subject: Question about REBIND message > > > > > > > > > Hello > > > > > > In the -18 rev, it is said that the client send the REBIND > > > message at T2 > > > (section 16.2) to 'any available server' in order to extend the > > > lifetimes of an IA, if the primary server has not > responded at T1. I > > > guess 'any available server' means any server which can > receive the > > > message (because it is onlink or via a relay). However, > according to > > > section 13.4.4 the server can successfully extend the > > > lifetimes only if > > > it has a binding for this client. > > > > thats correct. the idea is if another server thru some > other means can do > > this we don't want to prohibit the function for rebind. > > > Assume a server with no binding returns an IA > Empty/NoBinding REPLY > > > message before a server with a binding. How should we > handle this ? > > > Should we wait for an other reply ? How much time ? Same > thing for all > > > messages with 0 in the server-adress field. > > > > the client should react immediately is my view. this is a > case where we > > don't want mobile nodes hanging out. clients can always do > policing of > > packets esp mobile nodes. > > > > Ok, so the idea of REBIND is to try everything to keep a set of > addresses. > > Still one dark point: About 'reacting immediately', I've the feeling > that it works with one DHCP server in the domain. But with two ? For > instance, if the client has a binding with server A. For a > good reason, > it has to send a CONFIRM message. Server A and server B receive the > CONFIRM and answer. A returns a REPLY/status 0 and B returns a > REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by > the client and A's REPLY is received one or two ms after. If > the client > reacts immediately, according to section 13.3.5, it has to assume that > the IA is lost and that it needs to notify the application > layer and to > send a Request to reestablish an IA with B. The first REPLY is not > necessarily the best. I can't find anything in the spec about this. > > Jerome Labussiere > From owner-dhcp-v6@bucknell.edu Thu Mar 15 12:21:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03695; Thu, 15 Mar 2001 12:21:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FHICL27346; Thu, 15 Mar 2001 12:18:12 -0500 (EST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FHHvL22577 for ; Thu, 15 Mar 2001 12:17:57 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Mar 2001 09:18:30 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 09:18:33 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 15 Mar 2001 09:18:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4663.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: why seperate Ia is needed for sending new Requests? Date: Thu, 15 Mar 2001 09:18:32 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A681B6606@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: why seperate Ia is needed for sending new Requests? Thread-Index: AcCtbtdFCKV4+iR2Tl+ZgUa09zyyNwAA549w From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 15 Mar 2001 17:18:32.0953 (UTC) FILETIME=[F62F8E90:01C0AD73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f2FHHwL17927 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: 8bit If there is a facility to get additional addresses (which is present in the current draft) after the client boot in the spec, I think it is good. It is my experience in multicast address allocation that an app on the client may request an address anytime. There is even an RFC for the client APIs to request an address. (http://www.ietf.org/rfc/rfc2771.txt). In my opinion, address allocation problem in IPv6 will be somewhat similar to multicast address allocation in IPv4 mainly because of the presence of stateless address allocation protocol and the abundance of the address pool. thx -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, March 15, 2001 8:40 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? > In any case, it is likely that the DHCP client will have to generate IP > addresses on the fly using stateless/stateful configs. In other words, > the dhcpv6 spec shouldnt exclude this scenario as it is difficult to > predict the future. The current spec, as far as I can tell (and I am also quite interested in this), supports this scenario. I'm not convinced it's likely, but it is supported. You do it with multiple IAs. We were originally going to do it the way you're proposing, and it turned out that that was actually a _lot_ more complicated, because we had no key<->address set relationship. I say "address set" rather than "address" because even a very simple individual client that needs only one way of being contacted may still be assigned more than one address by the server. This is because the address the client has been using may be deprecated during a renumbering event, for example. In this case, the client will be given its old address, which is deprecated, along with a new address, which is be preferred for starting new network connections. Because we can't depend on there being a single address for a given client even under the most simple circumstances, we can't use the client's assigned address as an identifier. That's why we're now solving the problem with one logical identifier per address set rather than one logical identifier per client. The identity association is the tuple of (logical identifier, address set, ...), and the server can use the logical identifier as a key to look up this identity association. We will still have a unique per-client identifier. The IA identifier will be a single logical identifier per IA that is constructed in a well-defined way using the per-client identifier and a per-IA index. Do you think that this isn't going to work at all, or did we just not explain ourselves well enough, or is it just not the solution that you'd prefer? _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Mar 15 12:37:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04058 for ; Thu, 15 Mar 2001 12:37:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FHY1L17952; Thu, 15 Mar 2001 12:34:01 -0500 (EST) Received: from internaut.internaut.COM ([64.38.134.99]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FHXvL18958 for ; Thu, 15 Mar 2001 12:33:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.internaut.COM (8.9.3/8.9.3) with ESMTP id JAA08461; Thu, 15 Mar 2001 09:28:34 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 15 Mar 2001 09:28:34 -0800 (PST) From: Bernard Aboba To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: RE: why authenticate with DHCP? In-Reply-To: <13E2EF604DE5D111B2E50000F80824E806F2AEBC@zwdld001.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > [Roop says] Wireless networks are moving towards becoming all-IP above the > link layer. The push there as I understand it is to restrict the link and > physical layers to their original functions of getting the best (throughput, > loss delay etc.) out of the radio channel. What you've described is purely a function of the physical layer. You still need a MAC layer. And you still haven't described why PPP or 802 MAC won't work for you. > wire like links with IP and all of its companion protocols running over > them. Independence among layers and protocols is a crucial motivation. MAC layers are independent of the underlying PHYs. That is how PPP and 802 were architected. So the condition is already satisfied. > this argues for is that things like spread spectrum security should be dealt > with in lower layers Spectrum handling is by definition a PHY issue. This shouldn't affect upper layers at all (and doesn't in a correctly architected design). > but don't expect the lower layers to know about > communicating keys for protocols that are several layers above and are not > related to them. In practice, the way this works is that the chipsets support encryption in hardware (RC4, DES, AES), and enable keys to be loaded into the appropriate registers via a driver interface. It would be hard to build a chipset that wouldn't work with this architecture -- you have to have a way of loading keys if you're going to support hardware encryption. So while we might argue whether encryption should be a lower layer or higher level function, layer interfaces are not a problem. > [Roop says] It seems that the point you make below is that changing AAA is > cumbersome. Actually, my point is the opposite: AAA is architected to be extensible without code changes EXCEPT in the area of authentication where code changes are REQUIRED. In particular, the AAA for DHCP proposals will require MAJOR changes to the AAA architecture, because they not only involve new authentication methods, but also require AAA knowledge of DHCP. So those proposals are uniquely hard to implement. > this. All that needs to be done is to generate the AAA messages in a > language that an AAA server can presently understand and this is the > responsibility of the AAA client. Yes, life is easy for the AAA client. It is the AAA server that has to go through major contortions to support AAA for DHCP. > I do not see why putting it in link layer or higher will be an > advantage. The reason higher layer authentication has been such a huge issue for AAA is that major new AAA functionality has been required to accomodate it. In RFC 2869, we already put in a code extensibility architecture (EAP), but the upper layer authentication techniques (Mobile IP, AAA for DHCP) don't use it. As a result, these new functions require a massive AAA re-architecture, and in fact, are the major justification for an entirely new AAA protocol (DIAMETER). Accomodating AAA for DHCP would require yet another major re-architecture -- because now the AAA server wouldn't only have to understand basic network access (dialup, ADSL, 802, etc.) but also Mobile IP, DHCP and possibly other higher level protocols down the line. That is a very messy and ultimately unscalable architecture. In contrast, 802.1X was designed to fit into the existing AAA authentication extensibility architecture from the start (EAP), so that it will work with any RFC 2869 compliant RADIUS server out of the box. > [Roop says] It remains to be seen what protocol outlasts what in the > future, and should not be the basis for selecting or rejecting mechanisms > that can be of use the near term. Certainly, if can you ignore technical and market trends and commercial concerns, then the problem gets a lot easier. However, at some point, you will have to convince someone (customer, manager, etc.) why they should care. From owner-dhcp-v4@bucknell.edu Thu Mar 15 12:45:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04289 for ; Thu, 15 Mar 2001 12:45:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FHipL22346; Thu, 15 Mar 2001 12:44:51 -0500 (EST) Received: from internaut.internaut.COM ([64.38.134.99]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FHidL06713 for ; Thu, 15 Mar 2001 12:44:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.internaut.COM (8.9.3/8.9.3) with ESMTP id JAA08468; Thu, 15 Mar 2001 09:34:54 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 15 Mar 2001 09:34:54 -0800 (PST) From: Bernard Aboba To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: RE: why authenticate with DHCP? In-Reply-To: <13E2EF604DE5D111B2E50000F80824E806F2AEBC@zwdld001.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > [Roop says] Aside from the discussion about 802 being the protocol of the > future, I am trying to understand what is it that makes the link layer a > better place for a AAA client. AAA runs over IP, not the link layer. But AAA was designed for use in authentication and authorizing link layers, not upper layers. This meant that via use of a simple data model and support for a few built-in authentication types plus an auth extensibility model (EAP), AAA can easily accomodate a very wide variety of link layers. Accomodation of upper layer protocols has proved much more complex. For example, to accomodate Mobile IP, AAA has had to do things like address allocation, key generation and distribution, etc. It would appear that AAA support for DHCP will require similar major changes in functionality. From owner-dhcp-v6@bucknell.edu Thu Mar 15 16:47:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08892; Thu, 15 Mar 2001 16:47:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FLikL02501; Thu, 15 Mar 2001 16:44:46 -0500 (EST) 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 f2FLiXL10325; Thu, 15 Mar 2001 16:44:33 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA01542; Thu, 15 Mar 2001 16:43:43 -0500 (EST) Message-Id: <4.3.2.7.2.20010315164106.03531ca0@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 16:43:31 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Agenda for DHC WG meetings Cc: dhcp-v4@bucknell.edu, dhcp-v6@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 Monday, 3/19, 1530 Announcements from the chair Droms Authentication draft SIP server option Schulzrinne, 10 minutes Device class agent options Woundy, 10 minutes DHCP-DNS interaction - new drafts Stapp, 10 minutes Option concatenation Lemon, 10 minutes Classless static routes Lemon, 10 minutes Failover Kinnear, 5 minutes Leasequery Kinnear, 10 minutes Subnet selection sub-option Kinnear, 5 minutes VPN-id and VPN-id sub-option Kinnear, 10 minutes AAA and DHCP Tsirtsis, 20 minutes Wednesday, 3/21, 0930 Announcements from the chair Droms Review of changes in -18 draft Droms Review of design team teleconf Droms Outstanding issues Droms From owner-dhcp-v4@bucknell.edu Thu Mar 15 16:48:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08918 for ; Thu, 15 Mar 2001 16:48:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FLikL28102; Thu, 15 Mar 2001 16:44:46 -0500 (EST) 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 f2FLiXL10325; Thu, 15 Mar 2001 16:44:33 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA01542; Thu, 15 Mar 2001 16:43:43 -0500 (EST) Message-Id: <4.3.2.7.2.20010315164106.03531ca0@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 16:43:31 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Agenda for DHC WG meetings Cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu 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 Monday, 3/19, 1530 Announcements from the chair Droms Authentication draft SIP server option Schulzrinne, 10 minutes Device class agent options Woundy, 10 minutes DHCP-DNS interaction - new drafts Stapp, 10 minutes Option concatenation Lemon, 10 minutes Classless static routes Lemon, 10 minutes Failover Kinnear, 5 minutes Leasequery Kinnear, 10 minutes Subnet selection sub-option Kinnear, 5 minutes VPN-id and VPN-id sub-option Kinnear, 10 minutes AAA and DHCP Tsirtsis, 20 minutes Wednesday, 3/21, 0930 Announcements from the chair Droms Review of changes in -18 draft Droms Review of design team teleconf Droms Outstanding issues Droms From owner-dhcp-v4@bucknell.edu Thu Mar 15 17:01:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09096 for ; Thu, 15 Mar 2001 17:01:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FM0lL17012; Thu, 15 Mar 2001 17:00:47 -0500 (EST) 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 f2FM0OL13475 for ; Thu, 15 Mar 2001 17:00:24 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-64.cisco.com [161.44.133.64]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA03541; Thu, 15 Mar 2001 17:00:07 -0500 (EST) Message-Id: <4.2.0.58.20010315165621.01e4e0b0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Mar 2001 17:00:17 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: DHC WG agenda: pointers to some drafts 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 Folks: The following agenda items on the DHC WG agenda refer to the drafts in the links below. We (I) didn't manage to make the week early deadline for -00 WG drafts, so we submitted them as individual drafts for this time around. If you all think them "worthy", we'll submit them as WG drafts for London after a revision. Subnet selection sub-option Kinnear, 5 minutes http://www.ietf.org/internet-drafts/draft-kinnear-agent-subnet-selection-00.txt VPN-id and VPN-id sub-option Kinnear, 10 minutes http://www.ietf.org/internet-drafts/draft-johnson-vpn-id-option-00.txt http://www.ietf.org/internet-drafts/draft-kinnear-agent-vpn-id-00.txt Cheers -- Kim From owner-dhcp-v6@bucknell.edu Thu Mar 15 17:35:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09533; Thu, 15 Mar 2001 17:35:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FMXQL26955; Thu, 15 Mar 2001 17:33:26 -0500 (EST) 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 f2FMXIL30494; Thu, 15 Mar 2001 17:33:18 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA07659; Thu, 15 Mar 2001 17:33:01 -0500 (EST) Message-Id: <4.3.2.7.2.20010315173205.00b7bae8@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 17:32:49 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Meeting 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 I've posted webified agenda for the DHC WG meetings at http://www.dhcp.org/0103-meeting.html - Ralph From owner-dhcp-v4@bucknell.edu Thu Mar 15 17:38:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09590 for ; Thu, 15 Mar 2001 17:38:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FMXQL30262; Thu, 15 Mar 2001 17:33:26 -0500 (EST) 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 f2FMXIL30494; Thu, 15 Mar 2001 17:33:18 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA07659; Thu, 15 Mar 2001 17:33:01 -0500 (EST) Message-Id: <4.3.2.7.2.20010315173205.00b7bae8@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 17:32:49 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Meeting agenda 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 I've posted webified agenda for the DHC WG meetings at http://www.dhcp.org/0103-meeting.html - Ralph From owner-dhcp-v6@bucknell.edu Thu Mar 15 18:30:18 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10349; Thu, 15 Mar 2001 18:30:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2FNRhL11680; Thu, 15 Mar 2001 18:27:43 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2FNRWL30933 for ; Thu, 15 Mar 2001 18:27:32 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2FNRVi19184 for ; Thu, 15 Mar 2001 17:27:31 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2FNRUu29257 for ; Thu, 15 Mar 2001 17:27:31 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Mar 15 17:27:30 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 17:29:14 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB84B@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Thu, 15 Mar 2001 17:29:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ADA7.BEE8DED0" 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 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_001_01C0ADA7.BEE8DED0 Content-Type: text/plain; charset="iso-8859-1" There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too. If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it). - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] Sent: Thursday, March 15, 2001 10:32 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service. It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses. In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future. thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 15, 2001 5:17 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Vijay: Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on. Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests. Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior? - Bernie Volz -----Original Message----- From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] Sent: Thursday, March 15, 2001 7:02 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? so, the client won't ask that it wants "n" number of address. It will just send a blank request. The server will allocate the number of addresses according to its policy. In case, if the client needs some 10 addresses. If the server's policy is to allocate one IP-address per request, then, the client has to send 10 requests instead of asking a request of 10 IP-address. Isn't it? Is there any specific reason for bringing the control to the number of addresses allocated to the server from the client. Actually, the client has to ask for this much number of address and the server has to allocate it, if it is able to do so. I this is the correct approach. -Vijay > "Bernie Volz (EUD)" wrote: > > The problem with is approach is that is requires the client to know > how many addresses it wants. We don't want clients to have to know > this. All they should do is request addresses - how many are returned > is a server policy issue. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] > Sent: Wednesday, March 14, 2001 2:51 PM > To: DHCPv6 discussion list > Cc: rdroms@cisco.com; DHCPv6 discussion list > Subject: why seperate Ia is needed for sending new Requests? > > Hi Jim and Ralph, > > I have issues to discuss in telecon. > Why seperate IA is needed for sending new requests. > It can be send in the same IA itself. > This can be done very will the single IA. > sume the IA has already 2 addresses. Now, the client wants another > 3 addresses. For requesting another 3 addresses, send the same IA > option with following. > 1. make num-addrs field as 5. > 2. Include already existing 2 addresses in the IA option with filled > prefix length, IPv6 address and preferred lifetime and valid life time > > values. > For the remaining 3 address newly asked, fill the prefix length, > IPv6 address, pref-life time, valid-life time with zero and make the > corresponding VB> addr status to ADDR_REQUEST indicating, the client > is > asking the address. > > This has some advantages also. > 1. The DUID is need not to be generated for each and every request. > 2. The server can maintain the list of IP-address it is managing for > a particular interface of a node. This will minimize the number of > records maintained. > 3. If a client has sent 100 different requests, then it will have 100 > IAs. Thus the server has to sent unicast Reconfigure-init message to > the > same client 100 times, since the server no way identify the different > IAs belong to same client. > > Regards, > Vijay > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C0ADA7.BEE8DED0 Content-Type: text/html; charset="iso-8859-1" RE: why seperate Ia is needed for sending new Requests?
There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too.
 
If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it).
 
- Bernie
-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com]
Sent: Thursday, March 15, 2001 10:32 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service.
 
It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses.
 
In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future.
 
thx
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, March 15, 2001 5:17 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Vijay:

Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on.

Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests.

Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior?

- Bernie Volz

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, March 15, 2001 7:02 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests?


so, the client won't ask that it wants "n" number of address. It will
just send a blank request. The server will allocate the number of
addresses according to its policy. In case, if the client needs some 10
addresses. If the server's policy is to allocate one IP-address per
request, then, the client has to send 10 requests instead of asking a
request of 10 IP-address. Isn't it?
Is there any specific reason for bringing the control to the number of
addresses allocated to the server from the client. Actually, the client
has to ask for this much number of address and the server has to
allocate it, if it is able to do so. I this is the correct approach.

-Vijay
> "Bernie Volz (EUD)" wrote:
>
> The problem with is approach is that is requires the client to know
> how many addresses it wants. We don't want clients to have to know
> this. All they should do is request addresses - how many are returned
> is a server policy issue.
>
> - Bernie
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, March 14, 2001 2:51 PM
> To: DHCPv6 discussion list
> Cc: rdroms@cisco.com; DHCPv6 discussion list
> Subject: why seperate Ia is needed for sending new Requests?
>
> Hi Jim and Ralph,
>
> I have issues to discuss in telecon.
> Why seperate IA is needed for sending new requests.
> It can be send in the same IA itself.
>  This can be done very will the single IA.
> sume the IA has already 2 addresses. Now, the client wants another
> 3 addresses. For requesting another 3 addresses, send the same IA
> option with following.
> 1. make num-addrs field as 5.
> 2. Include already existing 2 addresses in the IA option with filled
> prefix length, IPv6 address and preferred lifetime and valid life time
>
> values.
> For the remaining 3 address newly asked, fill the prefix length,
> IPv6 address, pref-life time, valid-life time with zero and make the
> corresponding VB> addr status to ADDR_REQUEST indicating, the client
> is
> asking the address.
>
> This has some advantages also.
> 1. The DUID is need not to be generated for each and every request.
> 2. The server can maintain the list of IP-address it is managing for
> a particular interface of a node. This will minimize the number of
> records maintained.
> 3. If a client has sent 100 different requests, then it will have 100
> IAs. Thus the server has to sent unicast Reconfigure-init message to
> the
> same client 100 times, since the server no way identify the different
> IAs belong to same client.
>
> Regards,
> Vijay
>
> --
> ____Vijay_Bhaskar_A_K____
> ______Inet_Services______
> ________HP_ISO___________
> ____Ph:_2251554_1424_____
> ___Pager:_9624_371137____

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C0ADA7.BEE8DED0-- From owner-dhcp-v4@bucknell.edu Thu Mar 15 19:14:45 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10846 for ; Thu, 15 Mar 2001 19:14:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2G09aL24311; Thu, 15 Mar 2001 19:09:37 -0500 (EST) 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 f2G09SL12034 for ; Thu, 15 Mar 2001 19:09:28 -0500 (EST) Received: from grosse.bisbee.fugue.com (dhcp-239.rc.vix.com [204.152.187.239]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2DBoNg25084; Tue, 13 Mar 2001 03:50:23 -0800 (PST) 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 f2G09Gx00540; Thu, 15 Mar 2001 16:09:16 -0800 (PST) Message-Id: <200103160009.f2G09Gx00540@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHC WG agenda: pointers to some drafts In-Reply-To: Message from Kim Kinnear of "Thu, 15 Mar 2001 17:00:17 EST." <4.2.0.58.20010315165621.01e4e0b0@funnel.cisco.com> Date: Thu, 15 Mar 2001 16:09:16 -0800 From: Ted Lemon 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 thought the subnet selection option had made it to RFC status, no? _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Mar 15 19:15:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10861; Thu, 15 Mar 2001 19:15:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2G0D8L08663; Thu, 15 Mar 2001 19:13:08 -0500 (EST) 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 f2G0D2L24937 for ; Thu, 15 Mar 2001 19:13:02 -0500 (EST) Received: from grosse.bisbee.fugue.com (dhcp-239.rc.vix.com [204.152.187.239]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2DBrwg25089 for ; Tue, 13 Mar 2001 03:53:58 -0800 (PST) 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 f2G0Cox00554 for ; Thu, 15 Mar 2001 16:12:50 -0800 (PST) Message-Id: <200103160012.f2G0Cox00554@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 15 Mar 2001 17:29:14 CST." <66F66129A77AD411B76200508B65AC694CB84B@eambunt705.ena-east.ericsson.se> Date: Thu, 15 Mar 2001 16:12:50 -0800 From: Ted Lemon 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 you have a web hosting system, you might configure your DHCPv6 > server to give it LOTS of addresses (on one or more prefixes). That > would reduce the number of requests that system would need to > make. But, even if you don't, it can still get the addresses it wants > (provided the server's policy allows it). This is actually not at all what we talked about yesterday, if I understood correctly what we talked about. You don't need to configure the DHCP server to give the client more addresses - you just need to not configure it to refuse to accept multiple identity associations from the same client. And you need to configure the *client* to ask for multiple identity associations. Or did I misunderstand yesterday's conversation? _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Mar 15 19:34:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11078; Thu, 15 Mar 2001 19:34:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2G0X7L10404; Thu, 15 Mar 2001 19:33:07 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2G0X1L31489 for ; Thu, 15 Mar 2001 19:33:01 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2G0Wxi16166 for ; Thu, 15 Mar 2001 18:32:59 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2G0WxS12098 for ; Thu, 15 Mar 2001 18:32:59 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Mar 15 18:32:58 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 18:34:43 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB84F@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Thu, 15 Mar 2001 18:34:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ADB0.E49233D0" 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 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_001_01C0ADB0.E49233D0 Content-Type: text/plain; charset="iso-8859-1" No, Ted you are correct. I said you "might" configure your DHCPv6 server such. You certainly do not have to. The client can get more addresses by simply using multiple identify associations. In the question at hand, the system wanted say 1000 addresses. In that case (ASSUMING THE DHCPv6 SERVER ONLY GAVE BACK 1 ADDRESS PER IDENTITY ASSOCIATION), the problem is you'd have 1000 identity associations for that system (client). What I was suggesting is that in this case, you could make this more efficient by configuring the DHCPv6 server such that for that particular client, the server gave it "a lot of addresses" for each identity association. In my example, I said 50. Then the client only needs 20 identify associations for the 1000 addresses. Again, you *COULD* if the server provided this capability. You are NOT required to. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, March 15, 2001 7:13 PM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? > If you have a web hosting system, you might configure your DHCPv6 > server to give it LOTS of addresses (on one or more prefixes). That > would reduce the number of requests that system would need to > make. But, even if you don't, it can still get the addresses it wants > (provided the server's policy allows it). This is actually not at all what we talked about yesterday, if I understood correctly what we talked about. You don't need to configure the DHCP server to give the client more addresses - you just need to not configure it to refuse to accept multiple identity associations from the same client. And you need to configure the *client* to ask for multiple identity associations. Or did I misunderstand yesterday's conversation? _MelloN_ ------_=_NextPart_001_01C0ADB0.E49233D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?

No, Ted you are correct.

I said you "might" configure your DHCPv6 = server such. You certainly do not have to. The client can get more = addresses by simply using multiple identify associations.

In the question at hand, the system wanted say 1000 = addresses. In that case (ASSUMING THE DHCPv6 SERVER ONLY GAVE BACK 1 = ADDRESS PER IDENTITY ASSOCIATION), the problem is you'd have 1000 = identity associations for that system (client).

What I was suggesting is that in this case, you could = make this more efficient by configuring the DHCPv6 server such that for = that particular client, the server gave it "a lot of = addresses" for each identity association. In my example, I said = 50. Then the client only needs 20 identify associations for the 1000 = addresses.

Again, you *COULD* if the server provided this = capability. You are NOT required to.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, March 15, 2001 7:13 PM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending = new Requests?



> If you have a web hosting system, you might = configure your DHCPv6
> server to give it LOTS of addresses (on one or = more prefixes). That
> would reduce the number of requests that system = would need to
> make. But, even if you don't, it can still get = the addresses it wants
> (provided the server's policy allows = it).

This is actually not at all what we talked about = yesterday, if I
understood correctly what we talked = about.   You don't need to
configure the DHCP server to give the client more = addresses - you just
need to not configure it to refuse to accept = multiple identity
associations from the same client.   And = you need to configure the
*client* to ask for multiple identity = associations.   Or did I
misunderstand yesterday's conversation?

        =         =                _MelloN_

------_=_NextPart_001_01C0ADB0.E49233D0-- From owner-dhcp-v4@bucknell.edu Thu Mar 15 19:51:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11317 for ; Thu, 15 Mar 2001 19:51:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2G0kGL32520; Thu, 15 Mar 2001 19:46:16 -0500 (EST) Received: from tsmtp5.mail.isp (mailhost.teleline.es [195.235.113.141] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2G0k6L01382 for ; Thu, 15 Mar 2001 19:46:07 -0500 (EST) Received: from teleline.es ([10.10.21.70]) by tsmtp5.mail.isp (Netscape Messaging Server 4.15) with ESMTP id GA4TTO06.QT6 for ; Tue, 13 Mar 2001 11:44:12 +0100 From: JTACULOJ To: DHCPv4 discussion list Message-ID: <7229a7043f.7043f7229a@teleline.es> Date: Tue, 13 Mar 2001 11:44:13 +0100 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es X-Accept-Language: es Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f2G0k7L24010 Reply-To: JTACULOJ@terra.es Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-MIME-Autoconverted: from 8bit to quoted-printable by mail.bucknell.edu id f2G0kGL32520 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA11317 Hi all, I have the following configuration. we have more than 8 remote networks, each of then with their own C classs address range. Every network is connected throught a cisco router that uses ip helpper-address to ask for ip address to a dhcp server. Questions: 1) Can i have a single dhcp server that manage connections from clients and give them an IP of their range depending on source Router IP. 2) If I have two networks attached to the same router how can i give clients a ip of their range ( different DHCP server?, one for each ) 3) If i do, so can I have two or more DHCP instances on the same server (with different IP address (aliases), and different configuration Files on the same Machine). 4) Is this possible in a Linux Enviroment Any help would be apreciated, i think we are on trouble Thanks Jorge Cuesta López ___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES Haz clic en http://www.terra.es/correo/ From owner-dhcp-v6@bucknell.edu Thu Mar 15 19:57:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11388; Thu, 15 Mar 2001 19:57:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2G0vYL17491; Thu, 15 Mar 2001 19:57:34 -0500 (EST) 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 f2G0vNL01976 for ; Thu, 15 Mar 2001 19:57:23 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA19031; Thu, 15 Mar 2001 19:57:06 -0500 (EST) Message-Id: <4.3.2.7.2.20010315195235.00b7bae8@mail.bucknell.edu> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 19:56:52 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: why seperate Ia is needed for sending new Requests? Cc: DHCPv6 discussion list In-Reply-To: <78B1387745A15C46A7A727F2670D4A681B6605@DF-MILO.platinum.co rp.microsoft.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 If I remember correctly, we've considered the issue of virtual web servers in the past. Based on the capabilities of the current version of HTTP for identifying virtual web servers behind a single IP address, we've discarded virtual web servers as a motivation for on-demand address assignment. That's not to say there aren't other motivations for on-demand address assignment. Perhaps temporary addresses are a good motivating example. If we're going to add complexity to the protocol to support on-demand address assignment, we need to make sure we understand the specific motivations and requirements. - Ralph At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: >It is entirely possible for a client to ask for more "normal" addresses. >The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont >be. A server that does web hosting may need thousands of IP addresses and >it may not be possible to know the requirement ahead of time in all cases. >It will contact the DHCP Server to request more IP addresses in this case >or use stateless config to generate the IPs it needs. A server hosting >different services may want to use different "normal" addresses for each >service. From owner-dhcp-v6@bucknell.edu Fri Mar 16 00:54:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16529; Fri, 16 Mar 2001 00:54:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2G5pOL08037; Fri, 16 Mar 2001 00:51:24 -0500 (EST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2G5pBL09267 for ; Fri, 16 Mar 2001 00:51:11 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Mar 2001 21:51:43 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 21:51:47 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 15 Mar 2001 21:51:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4663.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: why seperate Ia is needed for sending new Requests? Date: Thu, 15 Mar 2001 21:51:46 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A681B6610@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: why seperate Ia is needed for sending new Requests? Thread-Index: AcCttEJu8hH6w4EcR560ZCj3koJbeAAJIV6g From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 16 Mar 2001 05:51:46.0766 (UTC) FILETIME=[2FCC26E0:01C0ADDD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f2G5pBL17359 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: 8bit I will try to enumerate several motivations for having the capability to request "normal" addresses in the future. a) Reservations: In Ipv6 there is no concept of reservations. However, "reservations" or static IP addresses will be required in some applications. In IPv4 itself, I have heard requests that there should be APIs to request multiple static addresses from a dhcp server. This is required in applications such as clustering where the same machine may have multiple IP addresses . The IP addresses may be used for each node in the cluter or for each service in the cluster. As an example, using Microsoft cluster service, it is possible to host a DHCP Server on one IP address and the WINS server on another IP address on the same cluster. It is not mandatory that the admin should have all the IP addresses at hand while configuring the cluster. The admin is free to add a service to the cluster any time he wants. In a IPv6 network, I can see the cluster service go to a dhcp server in the network to demand more "normal" addresses. b) A server hosting different network services. Let us take an example of a server that is hosting telnet server, tftp server and ftp server. In IPv4 world, the machine had one IP address and all the services bound to that IP address. I dont see this requirement in IPv6. It is entirely possible that each service will choose a different IP address to bind to. It is also possible for the administrator to add more network services after the initial boot of the server and it is desirable to have a way to get multiple addresses in the future. c) Multiple IP addresses per interface: Although it is possible to configure multiple IP addresses per interface today, it is not used widely in a lot of applications. This situation may change in a IPv6 world. A client may request 'n' addresses for a particular interface. d) The malloc ( Multicast Address Allocation ) group allows this feature in IPv4 multicast. RFCs 2730 and 2771. I see a lot of parallels with the IPv4 multicast address pool and IPv6 unicast address pool. ( in terms of the size/use of the address pool with respect to the available applications. ) The feature to request IP addresses at any time is being used by several multicast applications that need multicast address today. I can see the same scenario repeating in a IPv6 network. In RFC 2730, section 3.8, this is addressed as follows. 3.8. Number of Addresses Requested This option specifies the minimum and desired number of addresses requested by the client. It is only used in DISCOVER and REQUEST messages and is only sent by the client. The minimum and desired number of addresses requested are unsigned 16 bit integers in network byte order. The minimum MUST be less than or equal to the desired number. If a message is received where this is not the case, the MADCAP server MUST generate and process an Invalid Request error in the manner described in section 2.6. The client MAY obtain more than one address either by repeating the protocol for every address or by requesting several addresses at the same time via this option. When the client is requesting only one address, this option SHOULD NOT be included. A MADCAP server Hanna, et al. Standards Track [Page 34] RFC 2730 MADCAP December 1999 receiving a DISCOVER or REQUEST packet including this option MUST include between the minimum and desired number of addresses in any OFFER or ACK response. In RFC 2771, this is addressed in the following API. 3.1 Allocating multicast addresses: alloc_multicast_addr(in AddressFamily family, in Scope scope, in Integer minDesiredAddresses, in Integer maxDesiredAddresses, in Time minDesiredStartTime, in Time maxDesiredStartTime, in Time minDesiredLifetime, in Time maxDesiredLifetime, out Lease multicastAddressSetLease, out Status status) This operation attempts to allocate a set of multicast addresses (the size of this set is in the range [minDesiredAddresses, maxDesiredAddresses]) within the given address family and scope, and within a given range of desired lifetimes. ("minDesiredStartTime" and "maxDesiredStartTime" are used to specify "advance allocation"; this is described in more detail below.) If the address allocation succeeds, the result is returned in "multicastAddressSetLease" (with "status" = OK). During the lifetime of this lease, the allocation service will make a "best-effort" attempt to not allocate any of these addresses to others. (However, once the lease's lifetime has expired, any of its addresses can be allocated to others.) Multicast addresses are allocated for a limited lifetime. An application may attempt to extend this lifetime, but this operation may fail. Therefore, an application must be prepared for the possibility it will not be able to use the same addresses for as long as it desires. In particular, the application must be prepared to either quit early (because its original multicast address assignments have expired), or, alternatively, to occasionally 'renumber' its multicast addresses (in some application or higher-level-protocol dependent way), by making a new allocation. However, if an application needs to consider 'renumbering', it will always know this in advance, at the time it acquired its current address(es) - by checking the lifetime in the returned lease. An application will never need to be notified asynchronously of the need to 'renumber'. e) The only reason I see for not having a feature in the client not to request multiple IPs is the added complexity to the DHCPv6 draft. I do think that this is small price to pay compared to the inconveniences we will face because of this in the future. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, March 15, 2001 4:57 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? If I remember correctly, we've considered the issue of virtual web servers in the past. Based on the capabilities of the current version of HTTP for identifying virtual web servers behind a single IP address, we've discarded virtual web servers as a motivation for on-demand address assignment. That's not to say there aren't other motivations for on-demand address assignment. Perhaps temporary addresses are a good motivating example. If we're going to add complexity to the protocol to support on-demand address assignment, we need to make sure we understand the specific motivations and requirements. - Ralph At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: >It is entirely possible for a client to ask for more "normal" addresses. >The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont >be. A server that does web hosting may need thousands of IP addresses and >it may not be possible to know the requirement ahead of time in all cases. >It will contact the DHCP Server to request more IP addresses in this case >or use stateless config to generate the IPs it needs. A server hosting >different services may want to use different "normal" addresses for each >service. From owner-dhcp-v6@bucknell.edu Fri Mar 16 07:27:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02400; Fri, 16 Mar 2001 07:27:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GCPDL22488; Fri, 16 Mar 2001 07:25:13 -0500 (EST) 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 f2GCP1L20868; Fri, 16 Mar 2001 07:25:01 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA18763; Fri, 16 Mar 2001 07:24:44 -0500 (EST) Message-Id: <4.3.2.7.2.20010316072343.03605e98@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 07:24:31 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Updated agenda for Minneapolis Cc: aqenda@ietf.org 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 Monday, 1530-1730 - DHCPv4 agenda items DHC WG activities update Ralph Droms, 10 minutes DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes draft-ietf-sip-dhcp-04.txt Addition of Device Class to Agent Options Rich Woundy, 10 minutes draft-ietf-dhc-agentoptions-device-class-01.txt The DHCP Client FQDN Option Mark Stapp, 10 minutes draft-ietf-dhc-fqdn-option-01.txt Resolution of DNS Name Conflicts Among DHCP Clients draft-ietf-dhc-ddns-resolution-01.txt Encoding Long DHCP Options Ted Lemon, 10 minutes draft-ietf-dhc-concat-00.txt The Classless Static Route Option for DHCP Ted Lemon, 10 minutes draft-ietf-dhc-csr-04.txt DHCP Failover Protocol Kim Kinnear, 5 minutes draft-ietf-dhc-failover-08.txt DHCP Lease Query Kim Kinnear, 10 minutes draft-ietf-dhc-leasequery-01.txt Subnet Selection sub-option for Relay Kim Kinnear, 15 minutes Agent Information Option draft-kinnear-agent-subnet-selection-00.txt DHCP VPN Information option draft-johnson-vpn-id-option-00.txt VPN Identifier sub-option for Relay Agent Information Option draft-kinnear-agent-vpn-id-00.txt Triggering AAA from DHCP Relay Agents George Tsirtsis, 20 minutes draft-ietf-dhc-aaa-ra-00.txt Extensions to DHCP for Roaming Users Biswaroop Mukherjee, 15 minutes draft-mukherjee-dhc-dhcproam-01.txt ------------------------------------------------------------------------------- Wednesday, 0900-1130 - DHCPv6 review Dynamic Host Configuration Protocol Jim Bound, Ralph Droms for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-17.txt From owner-dhcp-v4@bucknell.edu Fri Mar 16 07:29:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02430 for ; Fri, 16 Mar 2001 07:29:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GCPDL13977; Fri, 16 Mar 2001 07:25:13 -0500 (EST) 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 f2GCP1L20868; Fri, 16 Mar 2001 07:25:01 -0500 (EST) Received: from rdroms-w2k.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA18763; Fri, 16 Mar 2001 07:24:44 -0500 (EST) Message-Id: <4.3.2.7.2.20010316072343.03605e98@funnel.cisco.com> X-Sender: rdroms@loopback X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 07:24:31 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Updated agenda for Minneapolis Cc: aqenda@ietf.org 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 Monday, 1530-1730 - DHCPv4 agenda items DHC WG activities update Ralph Droms, 10 minutes DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes draft-ietf-sip-dhcp-04.txt Addition of Device Class to Agent Options Rich Woundy, 10 minutes draft-ietf-dhc-agentoptions-device-class-01.txt The DHCP Client FQDN Option Mark Stapp, 10 minutes draft-ietf-dhc-fqdn-option-01.txt Resolution of DNS Name Conflicts Among DHCP Clients draft-ietf-dhc-ddns-resolution-01.txt Encoding Long DHCP Options Ted Lemon, 10 minutes draft-ietf-dhc-concat-00.txt The Classless Static Route Option for DHCP Ted Lemon, 10 minutes draft-ietf-dhc-csr-04.txt DHCP Failover Protocol Kim Kinnear, 5 minutes draft-ietf-dhc-failover-08.txt DHCP Lease Query Kim Kinnear, 10 minutes draft-ietf-dhc-leasequery-01.txt Subnet Selection sub-option for Relay Kim Kinnear, 15 minutes Agent Information Option draft-kinnear-agent-subnet-selection-00.txt DHCP VPN Information option draft-johnson-vpn-id-option-00.txt VPN Identifier sub-option for Relay Agent Information Option draft-kinnear-agent-vpn-id-00.txt Triggering AAA from DHCP Relay Agents George Tsirtsis, 20 minutes draft-ietf-dhc-aaa-ra-00.txt Extensions to DHCP for Roaming Users Biswaroop Mukherjee, 15 minutes draft-mukherjee-dhc-dhcproam-01.txt ------------------------------------------------------------------------------- Wednesday, 0900-1130 - DHCPv6 review Dynamic Host Configuration Protocol Jim Bound, Ralph Droms for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-17.txt From owner-dhcp-v4@bucknell.edu Fri Mar 16 09:01:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03796 for ; Fri, 16 Mar 2001 09:01:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GDumL11432; Fri, 16 Mar 2001 08:56:48 -0500 (EST) 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 f2GDuiL06665 for ; Fri, 16 Mar 2001 08:56:44 -0500 (EST) Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA24831; Fri, 16 Mar 2001 08:56:26 -0500 (EST) Message-Id: <4.3.2.7.2.20010316085513.00cf1660@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 08:56:12 -0500 To: DHCPv4 discussion list From: Mark Stapp Subject: Re: DHC WG agenda: pointers to some drafts Cc: DHCPv4 discussion list , DHCPv4 discussion list In-Reply-To: <200103160009.f2G09Gx00540@grosse.bisbee.fugue.com> References: <4.2.0.58.20010315165621.01e4e0b0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: mjs@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted, This is a new relay-agent option _sub_option that allows a relay to supply similar info. -- Mark At 04:09 PM 3/15/01 -0800, Ted Lemon wrote: >I thought the subnet selection option had made it to RFC status, no? > > _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Mar 16 09:18:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04006; Fri, 16 Mar 2001 09:18:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GEHSL24678; Fri, 16 Mar 2001 09:17:28 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GEHJL12486 for ; Fri, 16 Mar 2001 09:17:19 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2GEHFi23246 for ; Fri, 16 Mar 2001 08:17:15 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2GEHE524372 for ; Fri, 16 Mar 2001 08:17:14 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Mar 16 08:17:13 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 08:18:58 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB859@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 08:18:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE24.09C205E0" 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 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_001_01C0AE24.09C205E0 Content-Type: text/plain; charset="iso-8859-1" Hi: It may also be fairly easy to add this feature in the future. For example, the client could include an additional option that specifies the addresses requested (min ... max)? This option could also include the prefixes on which the addresses are requested (in cases where multiple prefixes are active on a single link). The option parameters might be a sequence of one or more of the following sets of data: - ID that this request goes with [this might not be needed if we 'order' options such that this appears BEFORE the Identity-Association to which it applies. - Address prefix (length + prefix) (all 0's if don't care) - Minimum number of addresses desired (16-bits?) - Maximum number of addresses desired (16-bits?) Note that the above option would be ignored by servers that don't support it. That may be bad. If that is a problem, an alternative is to define another 'address allocation request' option that basically is similar to the Identity-Association Option but adds some of the above data to allow a client to specify more details about the addresses it is looking for. But is something like this needed today in the 'core' protocol standard? I think the 'core' protocol standard has what's required now (and can even handle the requested requirements, although not as efficiently as might be desired). There will always be special applications that may need extensions, and we can easily add them later. Also, in the examples given below, it is unlikely that you'd need thousands of addresses. - Bernie Volz -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] Sent: Friday, March 16, 2001 12:52 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? I will try to enumerate several motivations for having the capability to request "normal" addresses in the future. a) Reservations: In Ipv6 there is no concept of reservations. However, "reservations" or static IP addresses will be required in some applications. In IPv4 itself, I have heard requests that there should be APIs to request multiple static addresses from a dhcp server. This is required in applications such as clustering where the same machine may have multiple IP addresses . The IP addresses may be used for each node in the cluter or for each service in the cluster. As an example, using Microsoft cluster service, it is possible to host a DHCP Server on one IP address and the WINS server on another IP address on the same cluster. It is not mandatory that the admin should have all the IP addresses at hand while configuring the cluster. The admin is free to add a service to the cluster any time he wants. In a IPv6 network, I can see the cluster service go to a dhcp server in the network to demand more "normal" addresses. b) A server hosting different network services. Let us take an example of a server that is hosting telnet server, tftp server and ftp server. In IPv4 world, the machine had one IP address and all the services bound to that IP address. I dont see this requirement in IPv6. It is entirely possible that each service will choose a different IP address to bind to. It is also possible for the administrator to add more network services after the initial boot of the server and it is desirable to have a way to get multiple addresses in the future. c) Multiple IP addresses per interface: Although it is possible to configure multiple IP addresses per interface today, it is not used widely in a lot of applications. This situation may change in a IPv6 world. A client may request 'n' addresses for a particular interface. d) The malloc ( Multicast Address Allocation ) group allows this feature in IPv4 multicast. RFCs 2730 and 2771. I see a lot of parallels with the IPv4 multicast address pool and IPv6 unicast address pool. ( in terms of the size/use of the address pool with respect to the available applications. ) The feature to request IP addresses at any time is being used by several multicast applications that need multicast address today. I can see the same scenario repeating in a IPv6 network. In RFC 2730, section 3.8, this is addressed as follows. 3.8. Number of Addresses Requested This option specifies the minimum and desired number of addresses requested by the client. It is only used in DISCOVER and REQUEST messages and is only sent by the client. The minimum and desired number of addresses requested are unsigned 16 bit integers in network byte order. The minimum MUST be less than or equal to the desired number. If a message is received where this is not the case, the MADCAP server MUST generate and process an Invalid Request error in the manner described in section 2.6. The client MAY obtain more than one address either by repeating the protocol for every address or by requesting several addresses at the same time via this option. When the client is requesting only one address, this option SHOULD NOT be included. A MADCAP server Hanna, et al. Standards Track [Page 34] RFC 2730 MADCAP December 1999 receiving a DISCOVER or REQUEST packet including this option MUST include between the minimum and desired number of addresses in any OFFER or ACK response. In RFC 2771, this is addressed in the following API. 3.1 Allocating multicast addresses: alloc_multicast_addr(in AddressFamily family, in Scope scope, in Integer minDesiredAddresses, in Integer maxDesiredAddresses, in Time minDesiredStartTime, in Time maxDesiredStartTime, in Time minDesiredLifetime, in Time maxDesiredLifetime, out Lease multicastAddressSetLease, out Status status) This operation attempts to allocate a set of multicast addresses (the size of this set is in the range [minDesiredAddresses, maxDesiredAddresses]) within the given address family and scope, and within a given range of desired lifetimes. ("minDesiredStartTime" and "maxDesiredStartTime" are used to specify "advance allocation"; this is described in more detail below.) If the address allocation succeeds, the result is returned in "multicastAddressSetLease" (with "status" = OK). During the lifetime of this lease, the allocation service will make a "best-effort" attempt to not allocate any of these addresses to others. (However, once the lease's lifetime has expired, any of its addresses can be allocated to others.) Multicast addresses are allocated for a limited lifetime. An application may attempt to extend this lifetime, but this operation may fail. Therefore, an application must be prepared for the possibility it will not be able to use the same addresses for as long as it desires. In particular, the application must be prepared to either quit early (because its original multicast address assignments have expired), or, alternatively, to occasionally 'renumber' its multicast addresses (in some application or higher-level-protocol dependent way), by making a new allocation. However, if an application needs to consider 'renumbering', it will always know this in advance, at the time it acquired its current address(es) - by checking the lifetime in the returned lease. An application will never need to be notified asynchronously of the need to 'renumber'. e) The only reason I see for not having a feature in the client not to request multiple IPs is the added complexity to the DHCPv6 draft. I do think that this is small price to pay compared to the inconveniences we will face because of this in the future. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, March 15, 2001 4:57 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? If I remember correctly, we've considered the issue of virtual web servers in the past. Based on the capabilities of the current version of HTTP for identifying virtual web servers behind a single IP address, we've discarded virtual web servers as a motivation for on-demand address assignment. That's not to say there aren't other motivations for on-demand address assignment. Perhaps temporary addresses are a good motivating example. If we're going to add complexity to the protocol to support on-demand address assignment, we need to make sure we understand the specific motivations and requirements. - Ralph At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: >It is entirely possible for a client to ask for more "normal" addresses. >The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont >be. A server that does web hosting may need thousands of IP addresses and >it may not be possible to know the requirement ahead of time in all cases. >It will contact the DHCP Server to request more IP addresses in this case >or use stateless config to generate the IPs it needs. A server hosting >different services may want to use different "normal" addresses for each >service. ------_=_NextPart_001_01C0AE24.09C205E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?

Hi:

It may also be fairly easy to add this feature in the = future. For example, the client could include an additional option that = specifies the addresses requested (min ... max)? This option could also = include the prefixes on which the addresses are requested (in cases = where multiple prefixes are active on a single link).

The option parameters might be a sequence of one or = more of the following sets of data:
- <Identity-Association> ID that this request = goes with [this might not be needed if we 'order' options such that = this appears BEFORE the Identity-Association to which it = applies.

- Address prefix (length + prefix) (all 0's if don't = care)
- Minimum number of addresses desired = (16-bits?)
- Maximum number of addresses desired = (16-bits?)

Note that the above option would be ignored by = servers that don't support it. That may be bad. If that is a problem, = an alternative is to define another 'address allocation request' option = that basically is similar to the Identity-Association Option but adds = some of the above data to allow a client to specify more details about = the addresses it is looking for.

But is something like this needed today in the 'core' = protocol standard? I think the 'core' protocol standard has what's = required now (and can even handle the requested requirements, although = not as efficiently as might be desired). There will always be special = applications that may need extensions, and we can easily add them = later.

Also, in the examples given below, it is unlikely = that you'd need thousands of addresses.

- Bernie Volz

-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@exchange.mic= rosoft.com]
Sent: Friday, March 16, 2001 12:52 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending = new Requests?


I will try to enumerate several motivations for = having the capability to
request "normal" addresses in the future. =

a) Reservations:
        In Ipv6 = there is no concept of reservations. However,
"reservations" or static IP addresses will = be required in some
applications. In IPv4 itself, I have heard requests = that there should be
APIs to request multiple static addresses from a = dhcp server. This is
required in applications such as clustering where = the same machine may
have multiple IP addresses . The IP addresses may be = used for each node
in the cluter or for each service in the cluster. As = an example, using
Microsoft cluster service, it is possible to host a = DHCP Server on one
IP address and the WINS server on another IP address = on the same
cluster. It is not mandatory that the admin should = have all the IP
addresses at hand while configuring the cluster. The = admin is free to
add a service to the cluster any time he wants. In a = IPv6 network, I can
see the cluster service go to a dhcp server in the = network to demand
more "normal" addresses.

b) A server hosting different network services. =
   Let us take an example of a server that = is hosting telnet server,
tftp server and ftp server. In IPv4 world, the = machine had one IP
address and all the services bound to that IP = address. I dont see this
requirement in IPv6. It is entirely possible that = each service will
choose a different IP address to bind to. It is also = possible for the
administrator to add more network services after the = initial boot of the
server and it is desirable to have a way to get = multiple addresses in
the future.

c) Multiple IP addresses per interface:
  Although it is possible to configure multiple = IP addresses per
interface today, it is not used widely in a lot of = applications. This
situation may change in a IPv6 world. A client may = request 'n' addresses
for a particular interface.

d) The malloc ( Multicast Address Allocation ) group = allows this feature
in IPv4 multicast. RFCs 2730 and 2771.
I see a lot of parallels with the IPv4 multicast = address pool and IPv6
unicast address pool. ( in terms of the size/use of = the address pool
with respect to the available applications. ) The = feature to request IP
addresses at any time is being used by several = multicast applications
that need multicast address today. I can see the = same scenario repeating
in a IPv6 network.

In RFC 2730, section 3.8, this is addressed as = follows.

3.8. Number of Addresses Requested

   This option specifies the minimum and = desired number of addresses
   requested by the client. It is only = used in DISCOVER and REQUEST
   messages and is only sent by the = client.

   The minimum and desired number of = addresses requested are unsigned 16
   bit integers in network byte order. The = minimum MUST be less than or
   equal to the desired number. If a = message is received where this is
   not the case, the MADCAP server MUST = generate and process an Invalid
   Request error in the manner described = in section 2.6.

   The client MAY obtain more than one = address either by repeating the
   protocol for every address or by = requesting several addresses at the
   same time via this option. When the = client is requesting only one
   address, this option SHOULD NOT be = included. A MADCAP server




Hanna, et = al.           &nb= sp;   Standards = Track           &= nbsp;        [Page 34]
=0C
RFC = 2730           &n= bsp;           &n= bsp; MADCAP          &= nbsp;         December = 1999


   receiving a DISCOVER or REQUEST packet = including this option MUST
   include between the minimum and desired = number of addresses in any
   OFFER or ACK response.

In RFC 2771, this is addressed in the following = API.

3.1 Allocating multicast addresses:

   alloc_multicast_addr(in AddressFamily = family,
          &nb= sp;           &nb= sp; in Scope scope,
          &nb= sp;           &nb= sp; in Integer minDesiredAddresses,
          &nb= sp;           &nb= sp; in Integer maxDesiredAddresses,
          &nb= sp;           &nb= sp; in Time minDesiredStartTime,
          &nb= sp;           &nb= sp; in Time maxDesiredStartTime,
          &nb= sp;           &nb= sp; in Time minDesiredLifetime,
          &nb= sp;           &nb= sp; in Time maxDesiredLifetime,
          &nb= sp;           &nb= sp; out Lease multicastAddressSetLease,
          &nb= sp;           &nb= sp; out Status status)

   This operation attempts to allocate a = set of multicast addresses (the
   size of this set is in the range = [minDesiredAddresses,
   maxDesiredAddresses]) within the given = address family and scope, and
   within a given range of desired = lifetimes.  ("minDesiredStartTime"
   and "maxDesiredStartTime" are = used to specify "advance allocation";
   this is described in more detail = below.)

   If the address allocation succeeds, the = result is returned in
   "multicastAddressSetLease" = (with "status" =3D OK).

   During the lifetime of this lease, the = allocation service will make a
   "best-effort" attempt to not = allocate any of these addresses to
   others.  (However, once the = lease's lifetime has expired, any of its
   addresses can be allocated to = others.)

   Multicast addresses are allocated for a = limited lifetime.  An
   application may attempt to extend this = lifetime, but this operation
   may fail.  Therefore, an = application must be prepared for the
   possibility it will not be able to use = the same addresses for as long
   as it desires.  In particular, the = application must be prepared to
   either quit early (because its original = multicast address assignments
   have expired), or, alternatively, to = occasionally 'renumber' its
   multicast addresses (in some = application or higher-level-protocol
   dependent way), by making a new = allocation.  However, if an
   application needs to consider = 'renumbering', it will always know this
   in advance, at the time it acquired its = current address(es) - by
   checking the lifetime in the returned = lease.  An application will
   never need to be notified = asynchronously of the need to 'renumber'.

 e) The only reason I see for not having a = feature in the client not to
request multiple IPs is the added complexity to the = DHCPv6 draft. I do
think that this is small price to pay compared to = the inconveniences we
will face because of this in the future.

thx





-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, March 15, 2001 4:57 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending = new Requests?


If I remember correctly, we've considered the issue = of virtual web
servers
in the past.  Based on the capabilities of the = current version of HTTP
for
identifying virtual web servers behind a single IP = address, we've
discarded
virtual web servers as a motivation for on-demand = address assignment.

That's not to say there aren't other motivations for = on-demand address
assignment.  Perhaps temporary addresses are a = good motivating example.
If
we're going to add complexity to the protocol to = support on-demand
address
assignment, we need to make sure we understand the = specific motivations
and
requirements.

- Ralph

At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat = wrote:
>It is entirely possible for a client to ask for = more "normal"
addresses.
>The reason being in IPv4, addresses were a = bottle neck and in IPv6 it
wont
>be. A server that does web hosting may need = thousands of IP addresses
and
>it may not be possible to know the requirement = ahead of time in all
cases.
>It will contact the DHCP Server to request more = IP addresses in this
case
>or use stateless config to generate the IPs it = needs. A server hosting
>different services may want to use different = "normal" addresses for
each
>service.

------_=_NextPart_001_01C0AE24.09C205E0-- From owner-dhcp-v4@bucknell.edu Fri Mar 16 09:24:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04106 for ; Fri, 16 Mar 2001 09:24:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GENgL23835; Fri, 16 Mar 2001 09:23:42 -0500 (EST) Received: from cits-darla.robins.af.mil (cits-darla.robins.af.mil [137.244.215.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GENaL23033 for ; Fri, 16 Mar 2001 09:23:36 -0500 (EST) Received: from cits-darla.robins.af.mil (root@localhost) by cits-darla.robins.af.mil with ESMTP id JAA15379 for ; Fri, 16 Mar 2001 09:18:45 -0500 (EST) Received: from sc216031.robins.af.mil (viruswall.robins.af.mil [137.244.216.31]) by cits-darla.robins.af.mil with SMTP id JAA15371 for ; Fri, 16 Mar 2001 09:18:45 -0500 (EST) Received: by fsuhhz30.robins.af.mil with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Mar 2001 14:23:17 -0000 Message-ID: From: Codding Deb A Contr 78 CS/SCBX To: DHCPv4 discussion list Subject: DHCP in routed network Date: Fri, 16 Mar 2001 14:23:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Reply-To: Deborah.Codding@robins.af.mil Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi! We are new to the DHCP environment and are trying to get it to run correctly. We have one DHCP server (using QIP DHCP server). The server is behind a router. Our basic network design has approximately 8 segments, with 6-8 subnets within each segment. In our testing we have set up an MS DHCP Relay Agent on the client side of the router. We are using manual DHCP tied to the MAC address. We have set the Relay Agent with virtual IPs for all of the subnets on the client side of the router. The problem we are encountering is that the Relay Agent makes the request based on its own IP, and therefore IPs are not getting assigned for any client that is not within the agent's subnet. Since we have 6-8 subnets on the client side, we need the server to assign the IP based on the subnet of the client, not the Relay Agent. We've searched the RFCs on this issue and it is pretty vague about configuring the Relay Agent to request the correct subnet, and we have not found anything on the MS Relay Agent that even allows us to specify the subnet we want based on the client making the discover request. Does anyone have any suggestions on how we can get the Relay Agent to let the DHCP server know which subnet it should assign from? Thanks, Deb Codding Systems Engineer Robins AFB, Georgia deborah.codding@robins.af.mil From owner-dhcp-v6@bucknell.edu Fri Mar 16 10:37:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05198; Fri, 16 Mar 2001 10:37:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GFYPL20197; Fri, 16 Mar 2001 10:34:25 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GFYAL12787 for ; Fri, 16 Mar 2001 10:34:11 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GFXpg04020 for ; Fri, 16 Mar 2001 09:34:01 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 09:33:48 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 09:33:48 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 09:33:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE2E.7E0C2E30" 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 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_001_01C0AE2E.7E0C2E30 Content-Type: text/plain; charset="iso-8859-1" true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too). /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday,March 15,2001 6:29 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too. If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it). - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] Sent: Thursday, March 15, 2001 10:32 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service. It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses. In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future. thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 15, 2001 5:17 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Vijay: Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on. Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests. Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior? - Bernie Volz -----Original Message----- From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] Sent: Thursday, March 15, 2001 7:02 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? so, the client won't ask that it wants "n" number of address. It will just send a blank request. The server will allocate the number of addresses according to its policy. In case, if the client needs some 10 addresses. If the server's policy is to allocate one IP-address per request, then, the client has to send 10 requests instead of asking a request of 10 IP-address. Isn't it? Is there any specific reason for bringing the control to the number of addresses allocated to the server from the client. Actually, the client has to ask for this much number of address and the server has to allocate it, if it is able to do so. I this is the correct approach. -Vijay > "Bernie Volz (EUD)" wrote: > > The problem with is approach is that is requires the client to know > how many addresses it wants. We don't want clients to have to know > this. All they should do is request addresses - how many are returned > is a server policy issue. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] > Sent: Wednesday, March 14, 2001 2:51 PM > To: DHCPv6 discussion list > Cc: rdroms@cisco.com; DHCPv6 discussion list > Subject: why seperate Ia is needed for sending new Requests? > > Hi Jim and Ralph, > > I have issues to discuss in telecon. > Why seperate IA is needed for sending new requests. > It can be send in the same IA itself. > This can be done very will the single IA. > sume the IA has already 2 addresses. Now, the client wants another > 3 addresses. For requesting another 3 addresses, send the same IA > option with following. > 1. make num-addrs field as 5. > 2. Include already existing 2 addresses in the IA option with filled > prefix length, IPv6 address and preferred lifetime and valid life time > > values. > For the remaining 3 address newly asked, fill the prefix length, > IPv6 address, pref-life time, valid-life time with zero and make the > corresponding VB> addr status to ADDR_REQUEST indicating, the client > is > asking the address. > > This has some advantages also. > 1. The DUID is need not to be generated for each and every request. > 2. The server can maintain the list of IP-address it is managing for > a particular interface of a node. This will minimize the number of > records maintained. > 3. If a client has sent 100 different requests, then it will have 100 > IAs. Thus the server has to sent unicast Reconfigure-init message to > the > same client 100 times, since the server no way identify the different > IAs belong to same client. > > Regards, > Vijay > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C0AE2E.7E0C2E30 Content-Type: text/html; charset="iso-8859-1" RE: why seperate Ia is needed for sending new Requests?
true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too). 
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday,March 15,2001 6:29 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too.
 
If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it).
 
- Bernie
-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com]
Sent: Thursday, March 15, 2001 10:32 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service.
 
It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses.
 
In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future.
 
thx
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, March 15, 2001 5:17 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Vijay:

Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on.

Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests.

Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior?

- Bernie Volz

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, March 15, 2001 7:02 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests?


so, the client won't ask that it wants "n" number of address. It will
just send a blank request. The server will allocate the number of
addresses according to its policy. In case, if the client needs some 10
addresses. If the server's policy is to allocate one IP-address per
request, then, the client has to send 10 requests instead of asking a
request of 10 IP-address. Isn't it?
Is there any specific reason for bringing the control to the number of
addresses allocated to the server from the client. Actually, the client
has to ask for this much number of address and the server has to
allocate it, if it is able to do so. I this is the correct approach.

-Vijay
> "Bernie Volz (EUD)" wrote:
>
> The problem with is approach is that is requires the client to know
> how many addresses it wants. We don't want clients to have to know
> this. All they should do is request addresses - how many are returned
> is a server policy issue.
>
> - Bernie
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, March 14, 2001 2:51 PM
> To: DHCPv6 discussion list
> Cc: rdroms@cisco.com; DHCPv6 discussion list
> Subject: why seperate Ia is needed for sending new Requests?
>
> Hi Jim and Ralph,
>
> I have issues to discuss in telecon.
> Why seperate IA is needed for sending new requests.
> It can be send in the same IA itself.
>  This can be done very will the single IA.
> sume the IA has already 2 addresses. Now, the client wants another
> 3 addresses. For requesting another 3 addresses, send the same IA
> option with following.
> 1. make num-addrs field as 5.
> 2. Include already existing 2 addresses in the IA option with filled
> prefix length, IPv6 address and preferred lifetime and valid life time
>
> values.
> For the remaining 3 address newly asked, fill the prefix length,
> IPv6 address, pref-life time, valid-life time with zero and make the
> corresponding VB> addr status to ADDR_REQUEST indicating, the client
> is
> asking the address.
>
> This has some advantages also.
> 1. The DUID is need not to be generated for each and every request.
> 2. The server can maintain the list of IP-address it is managing for
> a particular interface of a node. This will minimize the number of
> records maintained.
> 3. If a client has sent 100 different requests, then it will have 100
> IAs. Thus the server has to sent unicast Reconfigure-init message to
> the
> same client 100 times, since the server no way identify the different
> IAs belong to same client.
>
> Regards,
> Vijay
>
> --
> ____Vijay_Bhaskar_A_K____
> ______Inet_Services______
> ________HP_ISO___________
> ____Ph:_2251554_1424_____
> ___Pager:_9624_371137____

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C0AE2E.7E0C2E30-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 10:50:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05388; Fri, 16 Mar 2001 10:50:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GFoZL04887; Fri, 16 Mar 2001 10:50:35 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GFoLL16572 for ; Fri, 16 Mar 2001 10:50:21 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GFoMg07815 for ; Fri, 16 Mar 2001 09:50:22 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 09:50:19 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 09:50:19 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 09:50:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 hi ralph, I agree with you in spirit but the flesh is weak. we have chased the client telling servers "I want x addresses" for a long time. I suggest as I do for reconf-init multicast we not permit in our effort to get to PS. We will not reach consensus and the market is ready for dhcp using ipv6. I also believe reality is that most clients will get a default number of addresses from the server. clients that send another IA will get x addresses as they will be special anyway. So though in "theory" it seems messy, in practice I think it will work fine. for temporary addresses I think the client setting a bit in IA Status will tell the server I need to "note" temporary addresses. When the server responds it will send x addresses to the client. Before each address a bit will be set in the addr status field that this address is "noted" as temporary. I really don't think temporary addresses is a complex thing and I think we need to be careful we don't over complicate this part of what we need to do. at the server for the T1,T2,Preferred, and Valid lifetimes the server can apply the recommendations of rfc 3041 to the times it uses to provide the client leases. Pretty simplex stuff I think. then we just need to make a decision on whether we let server renew temporary addresses. in the design call I think I heard it was ok to extend the valid lifetime but not the preferred lifetime. I think we should be able to wrap this up at minneapolis. what would be really useful for the wed dhcpv6 venue is if ted could provide the format and datum picture of the IA + client-id parts for the IA option and the text for forming it so we can discuss. That is necessary to go to last call. I think this is the most important and critical item we work on next week. thanks /jim > -----Original Message----- > From: ext Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday,March 15,2001 7:57 PM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: RE: why seperate Ia is needed for sending new Requests? > > > If I remember correctly, we've considered the issue of > virtual web servers > in the past. Based on the capabilities of the current > version of HTTP for > identifying virtual web servers behind a single IP address, > we've discarded > virtual web servers as a motivation for on-demand address assignment. > > That's not to say there aren't other motivations for > on-demand address > assignment. Perhaps temporary addresses are a good > motivating example. If > we're going to add complexity to the protocol to support > on-demand address > assignment, we need to make sure we understand the specific > motivations and > requirements. > > - Ralph > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > >It is entirely possible for a client to ask for more > "normal" addresses. > >The reason being in IPv4, addresses were a bottle neck and > in IPv6 it wont > >be. A server that does web hosting may need thousands of IP > addresses and > >it may not be possible to know the requirement ahead of time > in all cases. > >It will contact the DHCP Server to request more IP addresses > in this case > >or use stateless config to generate the IPs it needs. A > server hosting > >different services may want to use different "normal" > addresses for each > >service. > > > From owner-dhcp-v6@bucknell.edu Fri Mar 16 11:07:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05765; Fri, 16 Mar 2001 11:07:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GG6ZL02860; Fri, 16 Mar 2001 11:06:35 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GG6WL03677 for ; Fri, 16 Mar 2001 11:06:32 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GG6Wg11206 for ; Fri, 16 Mar 2001 10:06:32 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 10:06:29 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 10:06:29 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 10:06:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 your right and some of these were used to support this in the past. I even agree with you 100%. But........we cannot get consensus on this right now is my feeling. the reason is the model to do what you asksn requires us as protocol developers to head down the path to permit clients to request addresses as they need them. this is like a new model. that new model causes other new models, etc. etc. so what we did was just eliminate this via the use of multiple IAs. True we don't let at client put xxx in num addrs today in the IA. This would be one way to do this in the existing draft 18. but I fear it will cause us to still be discussing that at the london ietf in aug 2000. that is not good for ipv6 or dhcpv6. what you suggest and I believe need (and others will) can be done using draft 18 with multiple IAs and server admin configuration. where I am coming from is kind of like when we all are building products and one very bright engineer is trying to put that last piece of elegant code into the source pool to get it just right and meet ALL requirements for performance, optimization, etc. but the lead engineer has to tell them "I hear you" but the customer needs this and we need to check this into the source pool like tonight to meet the next release of the product. dhcpv6 in the market is in that position. we need to ship a spec to the IESG after minneapolis I think. trying to get this in is going to slow things down unless some cosmic ray pops in and all see what your saying at the same time. plus our AD Thomas has put forth many many arguments against following this model right now. after we get all to agree with what we have now we can revisit extensions (as we will for many things I would imagine like all protocols do to evolve) the number of addresses field can be a place holder for tomorrow. but lets see if we can get what we have now blessed by the IESG, get PS status, get v6 implementors to build it. then we will hear lots of new input from deployment and the 3GPP IPv6 trials (one I am organizing now for Sept 2001 in Nice France). get kame and unh to build test suites etc... I support what your trying to do just ask that we try to move forward for now. If for some reason something else is going to slow us down to not get to the IESG like really quick after minneapolis I will be greatly disappointed and the market (customers) and then I would change my position if we are going to keep hacking on this and not get to PS. at least think about what I am saying if you can, thanks /jim > -----Original Message----- > From: ext Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] > Sent: Friday,March 16,2001 12:52 AM > To: DHCPv6 discussion list > Subject: RE: why seperate Ia is needed for sending new Requests? > > > I will try to enumerate several motivations for having the > capability to > request "normal" addresses in the future. > > a) Reservations: > In Ipv6 there is no concept of reservations. However, > "reservations" or static IP addresses will be required in some > applications. In IPv4 itself, I have heard requests that > there should be > APIs to request multiple static addresses from a dhcp server. This is > required in applications such as clustering where the same machine may > have multiple IP addresses . The IP addresses may be used for > each node > in the cluter or for each service in the cluster. As an example, using > Microsoft cluster service, it is possible to host a DHCP Server on one > IP address and the WINS server on another IP address on the same > cluster. It is not mandatory that the admin should have all the IP > addresses at hand while configuring the cluster. The admin is free to > add a service to the cluster any time he wants. In a IPv6 > network, I can > see the cluster service go to a dhcp server in the network to demand > more "normal" addresses. > > b) A server hosting different network services. > Let us take an example of a server that is hosting telnet server, > tftp server and ftp server. In IPv4 world, the machine had one IP > address and all the services bound to that IP address. I dont see this > requirement in IPv6. It is entirely possible that each service will > choose a different IP address to bind to. It is also possible for the > administrator to add more network services after the initial > boot of the > server and it is desirable to have a way to get multiple addresses in > the future. > > c) Multiple IP addresses per interface: > Although it is possible to configure multiple IP addresses per > interface today, it is not used widely in a lot of applications. This > situation may change in a IPv6 world. A client may request > 'n' addresses > for a particular interface. > > d) The malloc ( Multicast Address Allocation ) group allows > this feature > in IPv4 multicast. RFCs 2730 and 2771. > I see a lot of parallels with the IPv4 multicast address pool and IPv6 > unicast address pool. ( in terms of the size/use of the address pool > with respect to the available applications. ) The feature to > request IP > addresses at any time is being used by several multicast applications > that need multicast address today. I can see the same > scenario repeating > in a IPv6 network. > > In RFC 2730, section 3.8, this is addressed as follows. > > 3.8. Number of Addresses Requested > > This option specifies the minimum and desired number of addresses > requested by the client. It is only used in DISCOVER and REQUEST > messages and is only sent by the client. > > The minimum and desired number of addresses requested are > unsigned 16 > bit integers in network byte order. The minimum MUST be > less than or > equal to the desired number. If a message is received where this is > not the case, the MADCAP server MUST generate and process > an Invalid > Request error in the manner described in section 2.6. > > The client MAY obtain more than one address either by repeating the > protocol for every address or by requesting several > addresses at the > same time via this option. When the client is requesting only one > address, this option SHOULD NOT be included. A MADCAP server > > > > > Hanna, et al. Standards Track > [Page 34] > > > RFC 2730 MADCAP > December 1999 > > > receiving a DISCOVER or REQUEST packet including this option MUST > include between the minimum and desired number of addresses in any > OFFER or ACK response. > > In RFC 2771, this is addressed in the following API. > > 3.1 Allocating multicast addresses: > > alloc_multicast_addr(in AddressFamily family, > in Scope scope, > in Integer minDesiredAddresses, > in Integer maxDesiredAddresses, > in Time minDesiredStartTime, > in Time maxDesiredStartTime, > in Time minDesiredLifetime, > in Time maxDesiredLifetime, > out Lease multicastAddressSetLease, > out Status status) > > This operation attempts to allocate a set of multicast > addresses (the > size of this set is in the range [minDesiredAddresses, > maxDesiredAddresses]) within the given address family and > scope, and > within a given range of desired lifetimes. ("minDesiredStartTime" > and "maxDesiredStartTime" are used to specify "advance allocation"; > this is described in more detail below.) > > If the address allocation succeeds, the result is returned in > "multicastAddressSetLease" (with "status" = OK). > > During the lifetime of this lease, the allocation service > will make a > "best-effort" attempt to not allocate any of these addresses to > others. (However, once the lease's lifetime has expired, > any of its > addresses can be allocated to others.) > > Multicast addresses are allocated for a limited lifetime. An > application may attempt to extend this lifetime, but this operation > may fail. Therefore, an application must be prepared for the > possibility it will not be able to use the same addresses > for as long > as it desires. In particular, the application must be prepared to > either quit early (because its original multicast address > assignments > have expired), or, alternatively, to occasionally 'renumber' its > multicast addresses (in some application or higher-level-protocol > dependent way), by making a new allocation. However, if an > application needs to consider 'renumbering', it will > always know this > in advance, at the time it acquired its current address(es) - by > checking the lifetime in the returned lease. An application will > never need to be notified asynchronously of the need to 'renumber'. > > e) The only reason I see for not having a feature in the > client not to > request multiple IPs is the added complexity to the DHCPv6 draft. I do > think that this is small price to pay compared to the > inconveniences we > will face because of this in the future. > > thx > > > > > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, March 15, 2001 4:57 PM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: RE: why seperate Ia is needed for sending new Requests? > > > If I remember correctly, we've considered the issue of virtual web > servers > in the past. Based on the capabilities of the current version of HTTP > for > identifying virtual web servers behind a single IP address, we've > discarded > virtual web servers as a motivation for on-demand address assignment. > > That's not to say there aren't other motivations for > on-demand address > assignment. Perhaps temporary addresses are a good > motivating example. > If > we're going to add complexity to the protocol to support on-demand > address > assignment, we need to make sure we understand the specific > motivations > and > requirements. > > - Ralph > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > >It is entirely possible for a client to ask for more "normal" > addresses. > >The reason being in IPv4, addresses were a bottle neck and in IPv6 it > wont > >be. A server that does web hosting may need thousands of IP addresses > and > >it may not be possible to know the requirement ahead of time in all > cases. > >It will contact the DHCP Server to request more IP addresses in this > case > >or use stateless config to generate the IPs it needs. A > server hosting > >different services may want to use different "normal" addresses for > each > >service. > > From owner-dhcp-v4@bucknell.edu Fri Mar 16 11:32:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06394 for ; Fri, 16 Mar 2001 11:32:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GGQOL01950; Fri, 16 Mar 2001 11:26:24 -0500 (EST) Received: from bacon.intranet-solutions.com (bacon.intranet-solutions.com [195.173.37.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GGQFL20964 for ; Fri, 16 Mar 2001 11:26:15 -0500 (EST) Received: from ham.INTRANET-SOLUTIONS.COM ([194.159.157.193]) by bacon.intranet-solutions.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with ESMTP id AAA81; Fri, 16 Mar 2001 16:26:46 +0000 Received: from istechl2 (IS-TECH-L2.intranet-solutions.com [194.159.157.174]) by ham.INTRANET-SOLUTIONS.COM (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-55555U100L100S0) with SMTP id AAA178; Fri, 16 Mar 2001 16:27:27 +0000 From: "Paul Roberts" To: DHCPv4 discussion list Subject: RE: DHCP in routed network Date: Fri, 16 Mar 2001 16:29:29 -0000 Message-ID: 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Reply-To: paul.roberts@intranet-solutions.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit If you have a router installed then you should use the relay agent on the router, not a seperate NT box. If it's a Cisco router, use the ip-helper command to configure it. Regards, Paul Roberts Professional Services +---------------------------------------------+ | Paul Roberts, Intranet Solutions, | | Tel: +44 1252 849008 Fax: +44 1252 849097 | | E-mail: paul.roberts@intranet-solutions.com | | WWW: http://www.intranet-solutions.com | +---------------------------------------------+ > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Codding Deb A Contr 78 CS/SCBX > Sent: 16 March 2001 14:23 > To: DHCPv4 discussion list > Subject: DHCP in routed network > > > Hi! > > We are new to the DHCP environment and are trying to get it to run > correctly. We have one DHCP server (using QIP DHCP server). The > server is > behind a router. Our basic network design has approximately 8 segments, > with 6-8 subnets within each segment. In our testing we have set up an MS > DHCP Relay Agent on the client side of the router. We are using > manual DHCP > tied to the MAC address. We have set the Relay Agent with virtual IPs for > all of the subnets on the client side of the router. > > The problem we are encountering is that the Relay Agent makes the request > based on its own IP, and therefore IPs are not getting assigned for any > client that is not within the agent's subnet. Since we have 6-8 > subnets on > the client side, we need the server to assign the IP based on the > subnet of > the client, not the Relay Agent. We've searched the RFCs on this > issue and > it is pretty vague about configuring the Relay Agent to request > the correct > subnet, and we have not found anything on the MS Relay Agent that even > allows us to specify the subnet we want based on the client making the > discover request. > > Does anyone have any suggestions on how we can get the Relay Agent to let > the DHCP server know which subnet it should assign from? > > Thanks, > > Deb Codding > Systems Engineer > Robins AFB, Georgia > deborah.codding@robins.af.mil > From owner-dhcp-v6@bucknell.edu Fri Mar 16 11:45:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06775; Fri, 16 Mar 2001 11:45:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GGiJL03555; Fri, 16 Mar 2001 11:44:20 -0500 (EST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GGi7L21524 for ; Fri, 16 Mar 2001 11:44:07 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Mar 2001 08:44:39 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 08:44:43 -0800 (Pacific Standard Time) Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 16 Mar 2001 08:44:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4663.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 08:44:42 -0800 Message-ID: <78B1387745A15C46A7A727F2670D4A688C5B29@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: why seperate Ia is needed for sending new Requests? Thread-Index: AcCuM0G+E/0X/M2XSLuNgMd8Dgty8AABN6uA From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 16 Mar 2001 16:44:42.0789 (UTC) FILETIME=[6686DD50:01C0AE38] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f2GGi7L16266 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: 8bit I agree that there is a need to get the dhcpv6 draft completed soon. Since this is of great importance, let us move forward at this point. thx -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 8:06 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? your right and some of these were used to support this in the past. I even agree with you 100%. But........we cannot get consensus on this right now is my feeling. the reason is the model to do what you asksn requires us as protocol developers to head down the path to permit clients to request addresses as they need them. this is like a new model. that new model causes other new models, etc. etc. so what we did was just eliminate this via the use of multiple IAs. True we don't let at client put xxx in num addrs today in the IA. This would be one way to do this in the existing draft 18. but I fear it will cause us to still be discussing that at the london ietf in aug 2000. that is not good for ipv6 or dhcpv6. what you suggest and I believe need (and others will) can be done using draft 18 with multiple IAs and server admin configuration. where I am coming from is kind of like when we all are building products and one very bright engineer is trying to put that last piece of elegant code into the source pool to get it just right and meet ALL requirements for performance, optimization, etc. but the lead engineer has to tell them "I hear you" but the customer needs this and we need to check this into the source pool like tonight to meet the next release of the product. dhcpv6 in the market is in that position. we need to ship a spec to the IESG after minneapolis I think. trying to get this in is going to slow things down unless some cosmic ray pops in and all see what your saying at the same time. plus our AD Thomas has put forth many many arguments against following this model right now. after we get all to agree with what we have now we can revisit extensions (as we will for many things I would imagine like all protocols do to evolve) the number of addresses field can be a place holder for tomorrow. but lets see if we can get what we have now blessed by the IESG, get PS status, get v6 implementors to build it. then we will hear lots of new input from deployment and the 3GPP IPv6 trials (one I am organizing now for Sept 2001 in Nice France). get kame and unh to build test suites etc... I support what your trying to do just ask that we try to move forward for now. If for some reason something else is going to slow us down to not get to the IESG like really quick after minneapolis I will be greatly disappointed and the market (customers) and then I would change my position if we are going to keep hacking on this and not get to PS. at least think about what I am saying if you can, thanks /jim > -----Original Message----- > From: ext Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] > Sent: Friday,March 16,2001 12:52 AM > To: DHCPv6 discussion list > Subject: RE: why seperate Ia is needed for sending new Requests? > > > I will try to enumerate several motivations for having the > capability to > request "normal" addresses in the future. > > a) Reservations: > In Ipv6 there is no concept of reservations. However, > "reservations" or static IP addresses will be required in some > applications. In IPv4 itself, I have heard requests that > there should be > APIs to request multiple static addresses from a dhcp server. This is > required in applications such as clustering where the same machine may > have multiple IP addresses . The IP addresses may be used for > each node > in the cluter or for each service in the cluster. As an example, using > Microsoft cluster service, it is possible to host a DHCP Server on one > IP address and the WINS server on another IP address on the same > cluster. It is not mandatory that the admin should have all the IP > addresses at hand while configuring the cluster. The admin is free to > add a service to the cluster any time he wants. In a IPv6 > network, I can > see the cluster service go to a dhcp server in the network to demand > more "normal" addresses. > > b) A server hosting different network services. > Let us take an example of a server that is hosting telnet server, > tftp server and ftp server. In IPv4 world, the machine had one IP > address and all the services bound to that IP address. I dont see this > requirement in IPv6. It is entirely possible that each service will > choose a different IP address to bind to. It is also possible for the > administrator to add more network services after the initial > boot of the > server and it is desirable to have a way to get multiple addresses in > the future. > > c) Multiple IP addresses per interface: > Although it is possible to configure multiple IP addresses per > interface today, it is not used widely in a lot of applications. This > situation may change in a IPv6 world. A client may request > 'n' addresses > for a particular interface. > > d) The malloc ( Multicast Address Allocation ) group allows > this feature > in IPv4 multicast. RFCs 2730 and 2771. > I see a lot of parallels with the IPv4 multicast address pool and IPv6 > unicast address pool. ( in terms of the size/use of the address pool > with respect to the available applications. ) The feature to > request IP > addresses at any time is being used by several multicast applications > that need multicast address today. I can see the same > scenario repeating > in a IPv6 network. > > In RFC 2730, section 3.8, this is addressed as follows. > > 3.8. Number of Addresses Requested > > This option specifies the minimum and desired number of addresses > requested by the client. It is only used in DISCOVER and REQUEST > messages and is only sent by the client. > > The minimum and desired number of addresses requested are > unsigned 16 > bit integers in network byte order. The minimum MUST be > less than or > equal to the desired number. If a message is received where this is > not the case, the MADCAP server MUST generate and process > an Invalid > Request error in the manner described in section 2.6. > > The client MAY obtain more than one address either by repeating the > protocol for every address or by requesting several > addresses at the > same time via this option. When the client is requesting only one > address, this option SHOULD NOT be included. A MADCAP server > > > > > Hanna, et al. Standards Track > [Page 34] > > > RFC 2730 MADCAP > December 1999 > > > receiving a DISCOVER or REQUEST packet including this option MUST > include between the minimum and desired number of addresses in any > OFFER or ACK response. > > In RFC 2771, this is addressed in the following API. > > 3.1 Allocating multicast addresses: > > alloc_multicast_addr(in AddressFamily family, > in Scope scope, > in Integer minDesiredAddresses, > in Integer maxDesiredAddresses, > in Time minDesiredStartTime, > in Time maxDesiredStartTime, > in Time minDesiredLifetime, > in Time maxDesiredLifetime, > out Lease multicastAddressSetLease, > out Status status) > > This operation attempts to allocate a set of multicast > addresses (the > size of this set is in the range [minDesiredAddresses, > maxDesiredAddresses]) within the given address family and > scope, and > within a given range of desired lifetimes. ("minDesiredStartTime" > and "maxDesiredStartTime" are used to specify "advance allocation"; > this is described in more detail below.) > > If the address allocation succeeds, the result is returned in > "multicastAddressSetLease" (with "status" = OK). > > During the lifetime of this lease, the allocation service > will make a > "best-effort" attempt to not allocate any of these addresses to > others. (However, once the lease's lifetime has expired, > any of its > addresses can be allocated to others.) > > Multicast addresses are allocated for a limited lifetime. An > application may attempt to extend this lifetime, but this operation > may fail. Therefore, an application must be prepared for the > possibility it will not be able to use the same addresses > for as long > as it desires. In particular, the application must be prepared to > either quit early (because its original multicast address > assignments > have expired), or, alternatively, to occasionally 'renumber' its > multicast addresses (in some application or higher-level-protocol > dependent way), by making a new allocation. However, if an > application needs to consider 'renumbering', it will > always know this > in advance, at the time it acquired its current address(es) - by > checking the lifetime in the returned lease. An application will > never need to be notified asynchronously of the need to 'renumber'. > > e) The only reason I see for not having a feature in the > client not to > request multiple IPs is the added complexity to the DHCPv6 draft. I do > think that this is small price to pay compared to the > inconveniences we > will face because of this in the future. > > thx > > > > > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, March 15, 2001 4:57 PM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: RE: why seperate Ia is needed for sending new Requests? > > > If I remember correctly, we've considered the issue of virtual web > servers > in the past. Based on the capabilities of the current version of HTTP > for > identifying virtual web servers behind a single IP address, we've > discarded > virtual web servers as a motivation for on-demand address assignment. > > That's not to say there aren't other motivations for > on-demand address > assignment. Perhaps temporary addresses are a good > motivating example. > If > we're going to add complexity to the protocol to support on-demand > address > assignment, we need to make sure we understand the specific > motivations > and > requirements. > > - Ralph > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > >It is entirely possible for a client to ask for more "normal" > addresses. > >The reason being in IPv4, addresses were a bottle neck and in IPv6 it > wont > >be. A server that does web hosting may need thousands of IP addresses > and > >it may not be possible to know the requirement ahead of time in all > cases. > >It will contact the DHCP Server to request more IP addresses in this > case > >or use stateless config to generate the IPs it needs. A > server hosting > >different services may want to use different "normal" addresses for > each > >service. > > From owner-dhcp-v6@bucknell.edu Fri Mar 16 12:47:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07742; Fri, 16 Mar 2001 12:47:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GHiLL07108; Fri, 16 Mar 2001 12:44:21 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GHiJL20267 for ; Fri, 16 Mar 2001 12:44:19 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2GHiIi12981 for ; Fri, 16 Mar 2001 11:44:18 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2GHiI501288 for ; Fri, 16 Mar 2001 11:44:18 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Mar 16 11:44:17 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 11:46:02 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB860@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 11:45:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE40.F5F7C690" 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 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_001_01C0AE40.F5F7C690 Content-Type: text/plain; charset="iso-8859-1" Jim: Just as in DHCPv4 where an admin can use the haddr or client identifier, we'll be able to use the DUID (or whatever we end up calling it) to identify the client. So, why can't an admin add a policy for a specific client to give it addresses? Again, this is an implementation issue - your server may not offer this facility whereas one that I build could. Also, we'll likely add some sort of options to identify the 'class' or 'type' of client - perhaps that can be used as a trigger to the server to grant a specific number of addresses. - Bernie Volz -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 10:34 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too). /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday,March 15,2001 6:29 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too. If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it). - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] Sent: Thursday, March 15, 2001 10:32 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service. It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses. In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future. thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 15, 2001 5:17 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Vijay: Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on. Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests. Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior? - Bernie Volz -----Original Message----- From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] Sent: Thursday, March 15, 2001 7:02 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? so, the client won't ask that it wants "n" number of address. It will just send a blank request. The server will allocate the number of addresses according to its policy. In case, if the client needs some 10 addresses. If the server's policy is to allocate one IP-address per request, then, the client has to send 10 requests instead of asking a request of 10 IP-address. Isn't it? Is there any specific reason for bringing the control to the number of addresses allocated to the server from the client. Actually, the client has to ask for this much number of address and the server has to allocate it, if it is able to do so. I this is the correct approach. -Vijay > "Bernie Volz (EUD)" wrote: > > The problem with is approach is that is requires the client to know > how many addresses it wants. We don't want clients to have to know > this. All they should do is request addresses - how many are returned > is a server policy issue. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] > Sent: Wednesday, March 14, 2001 2:51 PM > To: DHCPv6 discussion list > Cc: rdroms@cisco.com; DHCPv6 discussion list > Subject: why seperate Ia is needed for sending new Requests? > > Hi Jim and Ralph, > > I have issues to discuss in telecon. > Why seperate IA is needed for sending new requests. > It can be send in the same IA itself. > This can be done very will the single IA. > sume the IA has already 2 addresses. Now, the client wants another > 3 addresses. For requesting another 3 addresses, send the same IA > option with following. > 1. make num-addrs field as 5. > 2. Include already existing 2 addresses in the IA option with filled > prefix length, IPv6 address and preferred lifetime and valid life time > > values. > For the remaining 3 address newly asked, fill the prefix length, > IPv6 address, pref-life time, valid-life time with zero and make the > corresponding VB> addr status to ADDR_REQUEST indicating, the client > is > asking the address. > > This has some advantages also. > 1. The DUID is need not to be generated for each and every request. > 2. The server can maintain the list of IP-address it is managing for > a particular interface of a node. This will minimize the number of > records maintained. > 3. If a client has sent 100 different requests, then it will have 100 > IAs. Thus the server has to sent unicast Reconfigure-init message to > the > same client 100 times, since the server no way identify the different > IAs belong to same client. > > Regards, > Vijay > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C0AE40.F5F7C690 Content-Type: text/html; charset="iso-8859-1" RE: why seperate Ia is needed for sending new Requests?
Jim:
 
Just as in DHCPv4 where an admin can use the haddr or client identifier, we'll be able to use the DUID (or whatever we end up calling it) to identify the client. So, why can't an admin add a policy for a specific client to give it <n> addresses? Again, this is an implementation issue - your server may not offer this facility whereas one that I build could.
 
Also, we'll likely add some sort of options to identify the 'class' or 'type' of client - perhaps that can be used as a trigger to the server to grant a specific number of addresses.
 
- Bernie Volz
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 10:34 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too). 
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday,March 15,2001 6:29 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too.
 
If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it).
 
- Bernie
-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com]
Sent: Thursday, March 15, 2001 10:32 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service.
 
It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses.
 
In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future.
 
thx
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, March 15, 2001 5:17 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Vijay:

Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on.

Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests.

Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior?

- Bernie Volz

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, March 15, 2001 7:02 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests?


so, the client won't ask that it wants "n" number of address. It will
just send a blank request. The server will allocate the number of
addresses according to its policy. In case, if the client needs some 10
addresses. If the server's policy is to allocate one IP-address per
request, then, the client has to send 10 requests instead of asking a
request of 10 IP-address. Isn't it?
Is there any specific reason for bringing the control to the number of
addresses allocated to the server from the client. Actually, the client
has to ask for this much number of address and the server has to
allocate it, if it is able to do so. I this is the correct approach.

-Vijay
> "Bernie Volz (EUD)" wrote:
>
> The problem with is approach is that is requires the client to know
> how many addresses it wants. We don't want clients to have to know
> this. All they should do is request addresses - how many are returned
> is a server policy issue.
>
> - Bernie
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, March 14, 2001 2:51 PM
> To: DHCPv6 discussion list
> Cc: rdroms@cisco.com; DHCPv6 discussion list
> Subject: why seperate Ia is needed for sending new Requests?
>
> Hi Jim and Ralph,
>
> I have issues to discuss in telecon.
> Why seperate IA is needed for sending new requests.
> It can be send in the same IA itself.
>  This can be done very will the single IA.
> sume the IA has already 2 addresses. Now, the client wants another
> 3 addresses. For requesting another 3 addresses, send the same IA
> option with following.
> 1. make num-addrs field as 5.
> 2. Include already existing 2 addresses in the IA option with filled
> prefix length, IPv6 address and preferred lifetime and valid life time
>
> values.
> For the remaining 3 address newly asked, fill the prefix length,
> IPv6 address, pref-life time, valid-life time with zero and make the
> corresponding VB> addr status to ADDR_REQUEST indicating, the client
> is
> asking the address.
>
> This has some advantages also.
> 1. The DUID is need not to be generated for each and every request.
> 2. The server can maintain the list of IP-address it is managing for
> a particular interface of a node. This will minimize the number of
> records maintained.
> 3. If a client has sent 100 different requests, then it will have 100
> IAs. Thus the server has to sent unicast Reconfigure-init message to
> the
> same client 100 times, since the server no way identify the different
> IAs belong to same client.
>
> Regards,
> Vijay
>
> --
> ____Vijay_Bhaskar_A_K____
> ______Inet_Services______
> ________HP_ISO___________
> ____Ph:_2251554_1424_____
> ___Pager:_9624_371137____

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C0AE40.F5F7C690-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 13:24:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08178; Fri, 16 Mar 2001 13:24:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GILlL29483; Fri, 16 Mar 2001 13:21:47 -0500 (EST) 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 f2GILZL32285 for ; Fri, 16 Mar 2001 13:21:35 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.121.190]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2E62Rg26108 for ; Tue, 13 Mar 2001 22:02:28 -0800 (PST) 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 f2GILTe00398 for ; Fri, 16 Mar 2001 10:21:29 -0800 (PST) Message-Id: <200103161821.f2GILTe00398@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? In-Reply-To: Message from "Bernie Volz (EUD)" of "Fri, 16 Mar 2001 08:18:57 CST." <66F66129A77AD411B76200508B65AC694CB859@eambunt705.ena-east.ericsson.se> Date: Fri, 16 Mar 2001 10:21:29 -0800 From: Ted Lemon 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 protocol as we have discussed it already provides a mechanism whereby a client can get more than one network identity (i.e., address set): the Identity Association. We do not know of a need for an additional mechanism, and the mechanism you described is basically the same one we rejected back at -14 or so, because while it looked easy in the packet, it was actually very complex to implement. It sounds like you don't want to do things the way you've proposed either - it was just an example of how things *might* be done differently - so let's just drop this and get on with the work at hand. I don't think there's any need to continue this discussion. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Mar 16 13:26:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08207; Fri, 16 Mar 2001 13:26:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GINuL31611; Fri, 16 Mar 2001 13:23:56 -0500 (EST) 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 f2GINsL01862 for ; Fri, 16 Mar 2001 13:23:54 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.121.190]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2E64lg26117 for ; Tue, 13 Mar 2001 22:04:47 -0800 (PST) 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 f2GINpe00418 for ; Fri, 16 Mar 2001 10:23:52 -0800 (PST) Message-Id: <200103161823.f2GINpe00418@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? In-Reply-To: Message from Jim.Bound@nokia.com of "Fri, 16 Mar 2001 09:33:47 CST." Date: Fri, 16 Mar 2001 10:23:51 -0800 From: Ted Lemon 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 bernie.....but as I said on the design con call I am not clear how the > admin differentiates one client from the other to satisfy specific client > requests as right now the client can't ask for any specific number of > addresses (which I support too). Most DHCPv4 servers provide ways of doing this - it's not a big problem, and there's no need to describe in the protocol spec how it should be implemented. The protocol already provides all the capability that's needed to do it, and how the vendor implements it is fairly straightforward. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Mar 16 13:29:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08257; Fri, 16 Mar 2001 13:29:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GIT5L22890; Fri, 16 Mar 2001 13:29:05 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GISlL06123 for ; Fri, 16 Mar 2001 13:28:48 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GISQg08888 for ; Fri, 16 Mar 2001 12:28:36 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 12:28:23 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 12:28:23 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 12:28:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE46.E1899D90" 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 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_001_01C0AE46.E1899D90 Content-Type: text/plain; charset="iso-8859-1" that fine......and I will work. thx /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday,March 16,2001 12:46 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Jim: Just as in DHCPv4 where an admin can use the haddr or client identifier, we'll be able to use the DUID (or whatever we end up calling it) to identify the client. So, why can't an admin add a policy for a specific client to give it addresses? Again, this is an implementation issue - your server may not offer this facility whereas one that I build could. Also, we'll likely add some sort of options to identify the 'class' or 'type' of client - perhaps that can be used as a trigger to the server to grant a specific number of addresses. - Bernie Volz -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 10:34 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too). /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday,March 15,2001 6:29 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too. If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it). - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] Sent: Thursday, March 15, 2001 10:32 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service. It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses. In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future. thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 15, 2001 5:17 AM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Vijay: Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on. Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests. Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior? - Bernie Volz -----Original Message----- From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] Sent: Thursday, March 15, 2001 7:02 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? so, the client won't ask that it wants "n" number of address. It will just send a blank request. The server will allocate the number of addresses according to its policy. In case, if the client needs some 10 addresses. If the server's policy is to allocate one IP-address per request, then, the client has to send 10 requests instead of asking a request of 10 IP-address. Isn't it? Is there any specific reason for bringing the control to the number of addresses allocated to the server from the client. Actually, the client has to ask for this much number of address and the server has to allocate it, if it is able to do so. I this is the correct approach. -Vijay > "Bernie Volz (EUD)" wrote: > > The problem with is approach is that is requires the client to know > how many addresses it wants. We don't want clients to have to know > this. All they should do is request addresses - how many are returned > is a server policy issue. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] > Sent: Wednesday, March 14, 2001 2:51 PM > To: DHCPv6 discussion list > Cc: rdroms@cisco.com; DHCPv6 discussion list > Subject: why seperate Ia is needed for sending new Requests? > > Hi Jim and Ralph, > > I have issues to discuss in telecon. > Why seperate IA is needed for sending new requests. > It can be send in the same IA itself. > This can be done very will the single IA. > sume the IA has already 2 addresses. Now, the client wants another > 3 addresses. For requesting another 3 addresses, send the same IA > option with following. > 1. make num-addrs field as 5. > 2. Include already existing 2 addresses in the IA option with filled > prefix length, IPv6 address and preferred lifetime and valid life time > > values. > For the remaining 3 address newly asked, fill the prefix length, > IPv6 address, pref-life time, valid-life time with zero and make the > corresponding VB> addr status to ADDR_REQUEST indicating, the client > is > asking the address. > > This has some advantages also. > 1. The DUID is need not to be generated for each and every request. > 2. The server can maintain the list of IP-address it is managing for > a particular interface of a node. This will minimize the number of > records maintained. > 3. If a client has sent 100 different requests, then it will have 100 > IAs. Thus the server has to sent unicast Reconfigure-init message to > the > same client 100 times, since the server no way identify the different > IAs belong to same client. > > Regards, > Vijay > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C0AE46.E1899D90 Content-Type: text/html; charset="iso-8859-1" RE: why seperate Ia is needed for sending new Requests?
that fine......and I will work.
thx
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday,March 16,2001 12:46 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Jim:
 
Just as in DHCPv4 where an admin can use the haddr or client identifier, we'll be able to use the DUID (or whatever we end up calling it) to identify the client. So, why can't an admin add a policy for a specific client to give it <n> addresses? Again, this is an implementation issue - your server may not offer this facility whereas one that I build could.
 
Also, we'll likely add some sort of options to identify the 'class' or 'type' of client - perhaps that can be used as a trigger to the server to grant a specific number of addresses.
 
- Bernie Volz
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 10:34 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too). 
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday,March 15,2001 6:29 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too.
 
If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it).
 
- Bernie
-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com]
Sent: Thursday, March 15, 2001 10:32 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

It is entirely possible for a client to ask for more "normal" addresses. The reason being in IPv4, addresses were a bottle neck and in IPv6 it wont be. A server that does web hosting may need thousands of IP addresses and it may not be possible to know the requirement ahead of time in all cases. It will contact the DHCP Server to request more IP addresses in this case or use stateless config to generate the IPs it needs. A server hosting different services may want to use different "normal" addresses for each service.
 
It is also possible for the client to use different IP addresses for different browser sessions. In this case, the client may request temporary addresses.
 
In any case, it is likely that the DHCP client will have to generate IP addresses on the fly using stateless/stateful configs. In other words, the dhcpv6 spec shouldnt exclude this scenario as it is difficult to predict the future.
 
thx
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, March 15, 2001 5:17 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Vijay:

Any design has trade offs. If a client were to ask for 5 addresses, what does that mean? Does it mean 5 addresses on a single prefix or on 5 different prefixes? Networks might have multiple prefixes active at one time, so asking for "n" addresses isn't all you'd have to do - the client would have to say give me "m" on prefix a, "o" on prefix b, and so on.

Normally clients will only ask for their 'normal' addressess. If they later need additional addresses (such as temporary ones), they can do additional requests.

Do you really expect a client to want to ask for many sets of addresses? If one excludes the temporary address issue, do you see a client ever asking for more 'normal' addresses? Yes, we have the mechanism by using the IA option, but is that likely to be the normal behavior?

- Bernie Volz

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, March 15, 2001 7:02 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests?


so, the client won't ask that it wants "n" number of address. It will
just send a blank request. The server will allocate the number of
addresses according to its policy. In case, if the client needs some 10
addresses. If the server's policy is to allocate one IP-address per
request, then, the client has to send 10 requests instead of asking a
request of 10 IP-address. Isn't it?
Is there any specific reason for bringing the control to the number of
addresses allocated to the server from the client. Actually, the client
has to ask for this much number of address and the server has to
allocate it, if it is able to do so. I this is the correct approach.

-Vijay
> "Bernie Volz (EUD)" wrote:
>
> The problem with is approach is that is requires the client to know
> how many addresses it wants. We don't want clients to have to know
> this. All they should do is request addresses - how many are returned
> is a server policy issue.
>
> - Bernie
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, March 14, 2001 2:51 PM
> To: DHCPv6 discussion list
> Cc: rdroms@cisco.com; DHCPv6 discussion list
> Subject: why seperate Ia is needed for sending new Requests?
>
> Hi Jim and Ralph,
>
> I have issues to discuss in telecon.
> Why seperate IA is needed for sending new requests.
> It can be send in the same IA itself.
>  This can be done very will the single IA.
> sume the IA has already 2 addresses. Now, the client wants another
> 3 addresses. For requesting another 3 addresses, send the same IA
> option with following.
> 1. make num-addrs field as 5.
> 2. Include already existing 2 addresses in the IA option with filled
> prefix length, IPv6 address and preferred lifetime and valid life time
>
> values.
> For the remaining 3 address newly asked, fill the prefix length,
> IPv6 address, pref-life time, valid-life time with zero and make the
> corresponding VB> addr status to ADDR_REQUEST indicating, the client
> is
> asking the address.
>
> This has some advantages also.
> 1. The DUID is need not to be generated for each and every request.
> 2. The server can maintain the list of IP-address it is managing for
> a particular interface of a node. This will minimize the number of
> records maintained.
> 3. If a client has sent 100 different requests, then it will have 100
> IAs. Thus the server has to sent unicast Reconfigure-init message to
> the
> same client 100 times, since the server no way identify the different
> IAs belong to same client.
>
> Regards,
> Vijay
>
> --
> ____Vijay_Bhaskar_A_K____
> ______Inet_Services______
> ________HP_ISO___________
> ____Ph:_2251554_1424_____
> ___Pager:_9624_371137____

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C0AE46.E1899D90-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 13:49:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08427; Fri, 16 Mar 2001 13:49:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GImkL22621; Fri, 16 Mar 2001 13:48:46 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GImaL07720 for ; Fri, 16 Mar 2001 13:48:37 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GImZg11468 for ; Fri, 16 Mar 2001 12:48:35 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 12:48:32 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 12:48:32 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: Client ID and DUID and variable within fixed bound Date: Fri, 16 Mar 2001 12:48:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Folks, On the design team there was some statements that the client-id + DUID would be variable. I have issues with variable after writing code for many years unless it is absolutely necessary. It complicates everything but I too have used it when it really made sense. Rather than bring this up at the meeting on Wednesday I thought I would try to get some discussion where people are coming from. Also variable within a bounded fixed-length as OSI NSAP address was in that protocol is at least a minimum requirement without serious justification. I would also state my gut feeling is that 128bits is more than enough for that fixed-length field based on old IPng and EID and to some degree NIMROD discussions days ago in the IETF for many years. Also for this we really need to think "mobile" wireless and its affect. And variable unbounded length fields cause optimizations and much variance in database and protocol datastructures. Anyway here is my belief of where we are with this IA DUID: 6 bytes - Hardware Address or possibly serial number 2 bytes - unique interface identifier the node keeps for each interface at the upper layer as it numbers them so it don't change 4 byte - timestamp 4 byte - TBD I am beginning to think the entire set of bytes is the DUID and the IA identifier? Can anyone state why we need more than 128bits? Discussion? thanks /jim From owner-dhcp-v6@bucknell.edu Fri Mar 16 14:55:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09927; Fri, 16 Mar 2001 14:55:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GJqpL14287; Fri, 16 Mar 2001 14:52:51 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GJqaL31826; Fri, 16 Mar 2001 14:52:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06513; Fri, 16 Mar 2001 11:51:53 -0800 (PST) Received: from rdroms-w2k.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GJpmg02013; Fri, 16 Mar 2001 11:51:48 -0800 (PST) Message-Id: <4.3.2.7.2.20010316145001.00b2f840@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 14:51:37 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Updated DHC WG agenda Cc: agenda@ietf.org 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 Monday, 1530-1730 - DHCPv4 agenda items DHC WG activities update Ralph Droms, 10 minutes DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt Addition of Device Class to Agent Options Rich Woundy, 10 minutes draft-ietf-dhc-agentoptions-device-class-01.txt The DHCP Client FQDN Option Mark Stapp, 10 minutes draft-ietf-dhc-fqdn-option-01.txt Resolution of DNS Name Conflicts Among DHCP Clients draft-ietf-dhc-ddns-resolution-01.txt Encoding Long DHCP Options Ted Lemon, 10 minutes draft-ietf-dhc-concat-00.txt The Classless Static Route Option for DHCP Ted Lemon, 10 minutes draft-ietf-dhc-csr-04.txt DHCP Failover Protocol Kim Kinnear, 5 minutes draft-ietf-dhc-failover-08.txt DHCP Lease Query Kim Kinnear, 10 minutes draft-ietf-dhc-leasequery-01.txt Subnet Selection sub-option for Relay Kim Kinnear, 15 minutes Agent Information Option draft-kinnear-agent-subnet-selection-00.txt DHCP VPN Information option draft-johnson-vpn-id-option-00.txt VPN Identifier sub-option for Relay Agent Information Option draft-kinnear-agent-vpn-id-00.txt Triggering AAA from DHCP Relay Agents George Tsirtsis, 20 minutes draft-ietf-dhc-aaa-ra-00.txt Extensions to DHCP for Roaming Users Biswaroop Mukherjee, 15 minutes draft-mukherjee-dhc-dhcproam-01.txt ------------------------------------------------------------------------------- Wednesday, 0900-1130 - DHCPv6 review Report from DDDT Design Team Bernard Aboba, 15 minutes Dynamic Host Configuration Protocol Jim Bound, Ralph Droms for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-17.txt - Review of changes in current draft - Review of design team teleconference - Discussion of outstanding issues From owner-dhcp-v4@bucknell.edu Fri Mar 16 14:58:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10021 for ; Fri, 16 Mar 2001 14:58:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GJqpL08830; Fri, 16 Mar 2001 14:52:51 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GJqaL31826; Fri, 16 Mar 2001 14:52:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06513; Fri, 16 Mar 2001 11:51:53 -0800 (PST) Received: from rdroms-w2k.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GJpmg02013; Fri, 16 Mar 2001 11:51:48 -0800 (PST) Message-Id: <4.3.2.7.2.20010316145001.00b2f840@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 14:51:37 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Updated DHC WG agenda Cc: agenda@ietf.org 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 Monday, 1530-1730 - DHCPv4 agenda items DHC WG activities update Ralph Droms, 10 minutes DHCP Option for SIP Servers Henning Schulzrinne, 20 minutes http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt Addition of Device Class to Agent Options Rich Woundy, 10 minutes draft-ietf-dhc-agentoptions-device-class-01.txt The DHCP Client FQDN Option Mark Stapp, 10 minutes draft-ietf-dhc-fqdn-option-01.txt Resolution of DNS Name Conflicts Among DHCP Clients draft-ietf-dhc-ddns-resolution-01.txt Encoding Long DHCP Options Ted Lemon, 10 minutes draft-ietf-dhc-concat-00.txt The Classless Static Route Option for DHCP Ted Lemon, 10 minutes draft-ietf-dhc-csr-04.txt DHCP Failover Protocol Kim Kinnear, 5 minutes draft-ietf-dhc-failover-08.txt DHCP Lease Query Kim Kinnear, 10 minutes draft-ietf-dhc-leasequery-01.txt Subnet Selection sub-option for Relay Kim Kinnear, 15 minutes Agent Information Option draft-kinnear-agent-subnet-selection-00.txt DHCP VPN Information option draft-johnson-vpn-id-option-00.txt VPN Identifier sub-option for Relay Agent Information Option draft-kinnear-agent-vpn-id-00.txt Triggering AAA from DHCP Relay Agents George Tsirtsis, 20 minutes draft-ietf-dhc-aaa-ra-00.txt Extensions to DHCP for Roaming Users Biswaroop Mukherjee, 15 minutes draft-mukherjee-dhc-dhcproam-01.txt ------------------------------------------------------------------------------- Wednesday, 0900-1130 - DHCPv6 review Report from DDDT Design Team Bernard Aboba, 15 minutes Dynamic Host Configuration Protocol Jim Bound, Ralph Droms for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-17.txt - Review of changes in current draft - Review of design team teleconference - Discussion of outstanding issues From owner-dhcp-v6@bucknell.edu Fri Mar 16 15:12:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10369; Fri, 16 Mar 2001 15:12:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GKC7L07164; Fri, 16 Mar 2001 15:12:07 -0500 (EST) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GKC1L31533 for ; Fri, 16 Mar 2001 15:12:01 -0500 (EST) Received: from hpda.cup.hp.com (hpda.cup.hp.com [15.75.208.53]) by atlrel2.hp.com (Postfix) with ESMTP id 3A20FA7F for ; Fri, 16 Mar 2001 15:12:01 -0500 (EST) Received: from hpindzob.nsr.hp.com (hpindzob.cup.hp.com [15.13.105.104]) by hpda.cup.hp.com (Postfix) with SMTP id DC8A86A6E for ; Fri, 16 Mar 2001 12:11:59 -0800 (PST) Message-ID: <005801c0ae55$5ad5fb40$68690d0f@nsr.hp.com> From: "ebenezer schubert" To: DHCPv6 discussion list References: Subject: Re: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 12:11:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 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 Hi, I would agree with what Jim is saying. The market is ready for DHCPv6 and we need some conclusion on this fast. At the same time there should be some scope for whatever the future versions to interoperate with the older ones. I would like to make 2 suggestions in this regard 1. To have an unimplemented error message. 2. To have a version field in the header. So that even if the IESG takes a long time to make a standard. We can proceed with the existing drafts, if the standard is different from the draft, we should be able to handle them easily. -ebi Hewlett-Packard 408-447-7652 ----- Original Message ----- From: To: DHCPv6 discussion list Sent: Friday, March 16, 2001 7:50 AM Subject: RE: why seperate Ia is needed for sending new Requests? > hi ralph, > > I agree with you in spirit but the flesh is weak. we have chased the client > telling servers "I want x addresses" for a long time. I suggest as I do for > reconf-init multicast we not permit in our effort to get to PS. We will not > reach consensus and the market is ready for dhcp using ipv6. I also believe > reality is that most clients will get a default number of addresses from the > server. clients that send another IA will get x addresses as they will be > special anyway. So though in "theory" it seems messy, in practice I think > it will work fine. > > for temporary addresses I think the client setting a bit in IA Status will > tell the server I need to "note" temporary addresses. When the server > responds it will send x addresses to the client. Before each address a bit > will be set in the addr status field that this address is "noted" as > temporary. I really don't think temporary addresses is a complex thing and > I think we need to be careful we don't over complicate this part of what we > need to do. at the server for the T1,T2,Preferred, and Valid lifetimes the > server can apply the recommendations of rfc 3041 to the times it uses to > provide the client leases. Pretty simplex stuff I think. then we just need > to make a decision on whether we let server renew temporary addresses. in > the design call I think I heard it was ok to extend the valid lifetime but > not the preferred lifetime. I think we should be able to wrap this up at > minneapolis. > > what would be really useful for the wed dhcpv6 venue is if ted could provide > the format and datum picture of the IA + client-id parts for the IA option > and the text for forming it so we can discuss. That is necessary to go to > last call. I think this is the most important and critical item we work on > next week. > > thanks > > /jim > > > -----Original Message----- > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Thursday,March 15,2001 7:57 PM > > To: DHCPv6 discussion list > > Cc: DHCPv6 discussion list > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > If I remember correctly, we've considered the issue of > > virtual web servers > > in the past. Based on the capabilities of the current > > version of HTTP for > > identifying virtual web servers behind a single IP address, > > we've discarded > > virtual web servers as a motivation for on-demand address assignment. > > > > That's not to say there aren't other motivations for > > on-demand address > > assignment. Perhaps temporary addresses are a good > > motivating example. If > > we're going to add complexity to the protocol to support > > on-demand address > > assignment, we need to make sure we understand the specific > > motivations and > > requirements. > > > > - Ralph > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > >It is entirely possible for a client to ask for more > > "normal" addresses. > > >The reason being in IPv4, addresses were a bottle neck and > > in IPv6 it wont > > >be. A server that does web hosting may need thousands of IP > > addresses and > > >it may not be possible to know the requirement ahead of time > > in all cases. > > >It will contact the DHCP Server to request more IP addresses > > in this case > > >or use stateless config to generate the IPs it needs. A > > server hosting > > >different services may want to use different "normal" > > addresses for each > > >service. > > > > > > > From owner-dhcp-v6@bucknell.edu Fri Mar 16 16:09:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13190; Fri, 16 Mar 2001 16:09:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GL6FL32466; Fri, 16 Mar 2001 16:06:15 -0500 (EST) Received: from gwa.ericsson.com (gwa.ericsson.com [198.215.127.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GL63L23157 for ; Fri, 16 Mar 2001 16:06:03 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.10.2/8.10.2) with ESMTP id f2GL5kA22172 for ; Fri, 16 Mar 2001 15:05:46 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2GL5kT00992 for ; Fri, 16 Mar 2001 15:05:46 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Mar 16 15:05:46 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 15:07:31 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB864@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Date: Fri, 16 Mar 2001 15:07:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE5D.184F36D0" 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 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_001_01C0AE5D.184F36D0 Content-Type: text/plain; charset="iso-8859-1" Jim: I don't have a problem with using a fixed identifer. Though, I don't see it being variable is such a big deal (especially if we set a reasonable upper limit). I think the DUID should just be the CLIENT IDENTIFIER. So, I would use something like: - 2 bytes - Type field (how the DUID is constructed, such as using the EUI-64 has a different value than if a serial number is used to prevent collisions) - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp The point is that a client thas ONE of this values and uses it for all DHCP requests (regardless of which interface or how many requests it is making). In many ways, having this be a 128-bit quantity is kind of nice. So, perhaps to increase the randomness of this, we use: - 2 bytes - Typ field - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp - 2 byte - random number Or, just specify the last 6 bytes as timestamp or other random number. What about running this through some short of hashing algorithm (such as what's proposed for the DHCID RR?) to allow the hardware address/serial number to be concealed (privacy concerns). We put this DUID into the packets - I think it should go into the header. But it could also be an option. For the Identity Association, we use an IdentityID value that is 32 or 64 bits. This value is contructed by client and is opaque. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 1:49 PM To: DHCPv6 discussion list Subject: Client ID and DUID and variable within fixed bound Folks, On the design team there was some statements that the client-id + DUID would be variable. I have issues with variable after writing code for many years unless it is absolutely necessary. It complicates everything but I too have used it when it really made sense. Rather than bring this up at the meeting on Wednesday I thought I would try to get some discussion where people are coming from. Also variable within a bounded fixed-length as OSI NSAP address was in that protocol is at least a minimum requirement without serious justification. I would also state my gut feeling is that 128bits is more than enough for that fixed-length field based on old IPng and EID and to some degree NIMROD discussions days ago in the IETF for many years. Also for this we really need to think "mobile" wireless and its affect. And variable unbounded length fields cause optimizations and much variance in database and protocol datastructures. Anyway here is my belief of where we are with this IA DUID: 6 bytes - Hardware Address or possibly serial number 2 bytes - unique interface identifier the node keeps for each interface at the upper layer as it numbers them so it don't change 4 byte - timestamp 4 byte - TBD I am beginning to think the entire set of bytes is the DUID and the IA identifier? Can anyone state why we need more than 128bits? Discussion? thanks /jim ------_=_NextPart_001_01C0AE5D.184F36D0 Content-Type: text/html; charset="iso-8859-1" RE: Client ID and DUID and variable within fixed bound

Jim:

I don't have a problem with using a fixed identifer. Though, I
don't see it being variable is such a big deal (especially if
we set a reasonable upper limit).

I think the DUID should just be the CLIENT IDENTIFIER. So, I
would use something like:
- 2 bytes - Type field (how the DUID is constructed, such as
  using the EUI-64 has a different value than if a serial number
  is used to prevent collisions)
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp

The point is that a client thas ONE of this values and uses it
for all DHCP requests (regardless of which interface or how many
requests it is making).

In many ways, having this be a 128-bit quantity is kind of nice.
So, perhaps to increase the randomness of this, we use:
- 2 bytes - Typ field
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp
- 2 byte  - random number
Or, just specify the last 6 bytes as timestamp or other random
number.

What about running this through some short of hashing algorithm
(such as what's proposed for the DHCID RR?) to allow the hardware
address/serial number to be concealed (privacy concerns).

We put this DUID into the packets - I think it should go into the
header. But it could also be an option.

For the Identity Association, we use an IdentityID value that is
32 or 64 bits. This value is contructed by client and is opaque.

- Bernie

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 1:49 PM
To: DHCPv6 discussion list
Subject: Client ID and DUID and variable within fixed bound


Folks,

On the design team there was some statements that the client-id + DUID would
be variable.  I have issues with variable after writing code for many years
unless it is absolutely necessary.  It complicates everything but I too have
used it when it really made sense.  Rather than bring this up at the meeting
on Wednesday I thought I would try to get some discussion where people are
coming from.

Also variable within a bounded fixed-length as OSI NSAP address was in that
protocol is at least a minimum requirement without serious justification. I
would also state my gut feeling is that 128bits is more than enough for that
fixed-length field based on old IPng and EID and to some degree NIMROD
discussions days ago in the IETF for many years.

Also for this we really need to think "mobile" wireless and its affect.  And
variable unbounded length fields cause optimizations and much variance in
database and protocol datastructures.  Anyway here is my belief of where we
are with this IA DUID:

6 bytes - Hardware Address or possibly serial number
2 bytes - unique interface identifier the node keeps for each interface at
          the upper layer as it numbers them so it don't change
4 byte  - timestamp
4 byte  - TBD

I am beginning to think the entire set of bytes is the DUID and the IA
identifier?

Can anyone state why we need more than 128bits?

Discussion?

thanks
/jim

------_=_NextPart_001_01C0AE5D.184F36D0-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 16:26:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13358; Fri, 16 Mar 2001 16:26:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GLQDL14153; Fri, 16 Mar 2001 16:26:13 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GLQ3L26541 for ; Fri, 16 Mar 2001 16:26:03 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GLPjg04173 for ; Fri, 16 Mar 2001 15:25:55 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 15:25:42 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 15:25:42 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 15:25:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 mean't to bring up the version number before. We were asked for this some time ago and a suggestion from several. I can't recall arguments against it and it may have fell through the cracks? /jim > -----Original Message----- > From: ext ebenezer schubert [mailto:ebi@cup.hp.com] > Sent: Friday,March 16,2001 3:12 PM > To: DHCPv6 discussion list > Subject: Re: why seperate Ia is needed for sending new Requests? > > > Hi, > > I would agree with what Jim is saying. The market > is ready for DHCPv6 and we need some conclusion > on this fast. > > At the same time there should be some scope for > whatever the future versions to interoperate with > the older ones. I would like to make 2 suggestions > in this regard > > 1. To have an unimplemented error message. > 2. To have a version field in the header. > > So that even if the IESG takes a long time to make > a standard. We can proceed with the existing drafts, > if the standard is different from the draft, we should > be able to handle them easily. > > > -ebi > Hewlett-Packard > 408-447-7652 > > ----- Original Message ----- > From: > To: DHCPv6 discussion list > Sent: Friday, March 16, 2001 7:50 AM > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > hi ralph, > > > > I agree with you in spirit but the flesh is weak. we have > chased the > client > > telling servers "I want x addresses" for a long time. I > suggest as I > do for > > reconf-init multicast we not permit in our effort to get to PS. We > will not > > reach consensus and the market is ready for dhcp using ipv6. I also > believe > > reality is that most clients will get a default number of addresses > from the > > server. clients that send another IA will get x addresses as they > will be > > special anyway. So though in "theory" it seems messy, in practice I > think > > it will work fine. > > > > for temporary addresses I think the client setting a bit in > IA Status > will > > tell the server I need to "note" temporary addresses. When the > server > > responds it will send x addresses to the client. Before > each address > a bit > > will be set in the addr status field that this address is "noted" as > > temporary. I really don't think temporary addresses is a complex > thing and > > I think we need to be careful we don't over complicate this part of > what we > > need to do. at the server for the T1,T2,Preferred, and Valid > lifetimes the > > server can apply the recommendations of rfc 3041 to the > times it uses > to > > provide the client leases. Pretty simplex stuff I think. then we > just need > > to make a decision on whether we let server renew temporary > addresses. in > > the design call I think I heard it was ok to extend the valid > lifetime but > > not the preferred lifetime. I think we should be able to wrap this > up at > > minneapolis. > > > > what would be really useful for the wed dhcpv6 venue is if ted could > provide > > the format and datum picture of the IA + client-id parts for the IA > option > > and the text for forming it so we can discuss. That is necessary to > go to > > last call. I think this is the most important and critical item we > work on > > next week. > > > > thanks > > > > /jim > > > > > -----Original Message----- > > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > > Sent: Thursday,March 15,2001 7:57 PM > > > To: DHCPv6 discussion list > > > Cc: DHCPv6 discussion list > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > If I remember correctly, we've considered the issue of > > > virtual web servers > > > in the past. Based on the capabilities of the current > > > version of HTTP for > > > identifying virtual web servers behind a single IP address, > > > we've discarded > > > virtual web servers as a motivation for on-demand address > assignment. > > > > > > That's not to say there aren't other motivations for > > > on-demand address > > > assignment. Perhaps temporary addresses are a good > > > motivating example. If > > > we're going to add complexity to the protocol to support > > > on-demand address > > > assignment, we need to make sure we understand the specific > > > motivations and > > > requirements. > > > > > > - Ralph > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > >It is entirely possible for a client to ask for more > > > "normal" addresses. > > > >The reason being in IPv4, addresses were a bottle neck and > > > in IPv6 it wont > > > >be. A server that does web hosting may need thousands of IP > > > addresses and > > > >it may not be possible to know the requirement ahead of time > > > in all cases. > > > >It will contact the DHCP Server to request more IP addresses > > > in this case > > > >or use stateless config to generate the IPs it needs. A > > > server hosting > > > >different services may want to use different "normal" > > > addresses for each > > > >service. > > > > > > > > > > > > From owner-dhcp-v6@bucknell.edu Fri Mar 16 16:33:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13494; Fri, 16 Mar 2001 16:33:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GLX5L06064; Fri, 16 Mar 2001 16:33:05 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GLX0L18658 for ; Fri, 16 Mar 2001 16:33:00 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28783 for ; Fri, 16 Mar 2001 13:32:49 -0800 (PST) Received: from rdroms-w2k.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GLWg729344 for ; Fri, 16 Mar 2001 13:32:43 -0800 (PST) Message-Id: <4.3.2.7.2.20010316162832.0364a8f0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 16:32:31 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Doc to review for WG meeting 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 Bernard Aboba is on the agenda for Wednesday to discuss the report from the DDDT: Analysis of DNS Server Discovery Mechanisms for IPv6 - Ralph From owner-dhcp-v6@bucknell.edu Fri Mar 16 16:43:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13654; Fri, 16 Mar 2001 16:43:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GLfAL06651; Fri, 16 Mar 2001 16:41:10 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GLexL17873 for ; Fri, 16 Mar 2001 16:40:59 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GLgpw05702 for ; Fri, 16 Mar 2001 15:42:51 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 15:40:57 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 15:40:56 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Date: Fri, 16 Mar 2001 15:40:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE61.C7D48BB0" 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 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_001_01C0AE61.C7D48BB0 Content-Type: text/plain; charset="iso-8859-1" Bernie, I said I can live with variable as long as there is upper limit (thats what OSI NSAP did). I am less clear right now if identity id should be different than client-id. I have no issue with your proposed fields at first glance. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday,March 16,2001 4:07 PM To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Jim: I don't have a problem with using a fixed identifer. Though, I don't see it being variable is such a big deal (especially if we set a reasonable upper limit). I think the DUID should just be the CLIENT IDENTIFIER. So, I would use something like: - 2 bytes - Type field (how the DUID is constructed, such as using the EUI-64 has a different value than if a serial number is used to prevent collisions) - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp The point is that a client thas ONE of this values and uses it for all DHCP requests (regardless of which interface or how many requests it is making). In many ways, having this be a 128-bit quantity is kind of nice. So, perhaps to increase the randomness of this, we use: - 2 bytes - Typ field - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp - 2 byte - random number Or, just specify the last 6 bytes as timestamp or other random number. What about running this through some short of hashing algorithm (such as what's proposed for the DHCID RR?) to allow the hardware address/serial number to be concealed (privacy concerns). We put this DUID into the packets - I think it should go into the header. But it could also be an option. For the Identity Association, we use an IdentityID value that is 32 or 64 bits. This value is contructed by client and is opaque. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [ mailto:Jim.Bound@nokia.com ] Sent: Friday, March 16, 2001 1:49 PM To: DHCPv6 discussion list Subject: Client ID and DUID and variable within fixed bound Folks, On the design team there was some statements that the client-id + DUID would be variable. I have issues with variable after writing code for many years unless it is absolutely necessary. It complicates everything but I too have used it when it really made sense. Rather than bring this up at the meeting on Wednesday I thought I would try to get some discussion where people are coming from. Also variable within a bounded fixed-length as OSI NSAP address was in that protocol is at least a minimum requirement without serious justification. I would also state my gut feeling is that 128bits is more than enough for that fixed-length field based on old IPng and EID and to some degree NIMROD discussions days ago in the IETF for many years. Also for this we really need to think "mobile" wireless and its affect. And variable unbounded length fields cause optimizations and much variance in database and protocol datastructures. Anyway here is my belief of where we are with this IA DUID: 6 bytes - Hardware Address or possibly serial number 2 bytes - unique interface identifier the node keeps for each interface at the upper layer as it numbers them so it don't change 4 byte - timestamp 4 byte - TBD I am beginning to think the entire set of bytes is the DUID and the IA identifier? Can anyone state why we need more than 128bits? Discussion? thanks /jim ------_=_NextPart_001_01C0AE61.C7D48BB0 Content-Type: text/html; charset="iso-8859-1" RE: Client ID and DUID and variable within fixed bound
Bernie,
 
I said I can live with variable as long as there is upper limit (thats what OSI NSAP did).
I am less clear right now if identity id should be different than client-id.
I have no issue with your proposed fields at first glance.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday,March 16,2001 4:07 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Jim:

I don't have a problem with using a fixed identifer. Though, I
don't see it being variable is such a big deal (especially if
we set a reasonable upper limit).

I think the DUID should just be the CLIENT IDENTIFIER. So, I
would use something like:
- 2 bytes - Type field (how the DUID is constructed, such as
  using the EUI-64 has a different value than if a serial number
  is used to prevent collisions)
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp

The point is that a client thas ONE of this values and uses it
for all DHCP requests (regardless of which interface or how many
requests it is making).

In many ways, having this be a 128-bit quantity is kind of nice.
So, perhaps to increase the randomness of this, we use:
- 2 bytes - Typ field
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp
- 2 byte  - random number
Or, just specify the last 6 bytes as timestamp or other random
number.

What about running this through some short of hashing algorithm
(such as what's proposed for the DHCID RR?) to allow the hardware
address/serial number to be concealed (privacy concerns).

We put this DUID into the packets - I think it should go into the
header. But it could also be an option.

For the Identity Association, we use an IdentityID value that is
32 or 64 bits. This value is contructed by client and is opaque.

- Bernie

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 1:49 PM
To: DHCPv6 discussion list
Subject: Client ID and DUID and variable within fixed bound


Folks,

On the design team there was some statements that the client-id + DUID would
be variable.  I have issues with variable after writing code for many years
unless it is absolutely necessary.  It complicates everything but I too have
used it when it really made sense.  Rather than bring this up at the meeting
on Wednesday I thought I would try to get some discussion where people are
coming from.

Also variable within a bounded fixed-length as OSI NSAP address was in that
protocol is at least a minimum requirement without serious justification. I
would also state my gut feeling is that 128bits is more than enough for that
fixed-length field based on old IPng and EID and to some degree NIMROD
discussions days ago in the IETF for many years.

Also for this we really need to think "mobile" wireless and its affect.  And
variable unbounded length fields cause optimizations and much variance in
database and protocol datastructures.  Anyway here is my belief of where we
are with this IA DUID:

6 bytes - Hardware Address or possibly serial number
2 bytes - unique interface identifier the node keeps for each interface at
          the upper layer as it numbers them so it don't change
4 byte  - timestamp
4 byte  - TBD

I am beginning to think the entire set of bytes is the DUID and the IA
identifier?

Can anyone state why we need more than 128bits?

Discussion?

thanks
/jim

------_=_NextPart_001_01C0AE61.C7D48BB0-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 16:51:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13746; Fri, 16 Mar 2001 16:51:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GLoVL19671; Fri, 16 Mar 2001 16:50:31 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GLoHL07712 for ; Fri, 16 Mar 2001 16:50:17 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2GLoFm23098 for ; Fri, 16 Mar 2001 15:50:16 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2GLoFT19733 for ; Fri, 16 Mar 2001 15:50:15 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Mar 16 15:50:14 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 15:52:00 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB865@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Date: Fri, 16 Mar 2001 15:51:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE63.522CD8C0" 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 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_001_01C0AE63.522CD8C0 Content-Type: text/plain; charset="iso-8859-1" Great. Regarding identity id, are you referring to what goes into the Identity Association option? That should be different. The client id needs to go into the ALL requests even if the client isn't asking for addresses. Reason is we need some way to identify the client that is making a request - such that a server can: a) Track what a client has. Since there are applications where you might want to restrict that. b) You have some useful and meaningful value by which to track who had an address when. Just having a value that can constantly change doesn't buy you anything. Sure, you could record the client link-local address but that is unique only to a link (prefix). c) We need some id that we can use in the DHCID RR so that a single client is allowed to register multiple addresses under one name. If the client always registers the forward (A6) entry, then it could use some other identifier. However, if the server is doing it it needs some way to know that the existing belongs to the same client. d) If you want to do client specific reservations (either specific addresses or number of addresses) OR want to give a specific client some set of configuration parameters (perhaps other than addresses), you need something by which to identify that client. Do you need more reasons? - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 4:41 PM To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Bernie, I said I can live with variable as long as there is upper limit (thats what OSI NSAP did). I am less clear right now if identity id should be different than client-id. I have no issue with your proposed fields at first glance. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday,March 16,2001 4:07 PM To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Jim: I don't have a problem with using a fixed identifer. Though, I don't see it being variable is such a big deal (especially if we set a reasonable upper limit). I think the DUID should just be the CLIENT IDENTIFIER. So, I would use something like: - 2 bytes - Type field (how the DUID is constructed, such as using the EUI-64 has a different value than if a serial number is used to prevent collisions) - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp The point is that a client thas ONE of this values and uses it for all DHCP requests (regardless of which interface or how many requests it is making). In many ways, having this be a 128-bit quantity is kind of nice. So, perhaps to increase the randomness of this, we use: - 2 bytes - Typ field - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp - 2 byte - random number Or, just specify the last 6 bytes as timestamp or other random number. What about running this through some short of hashing algorithm (such as what's proposed for the DHCID RR?) to allow the hardware address/serial number to be concealed (privacy concerns). We put this DUID into the packets - I think it should go into the header. But it could also be an option. For the Identity Association, we use an IdentityID value that is 32 or 64 bits. This value is contructed by client and is opaque. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [ mailto:Jim.Bound@nokia.com ] Sent: Friday, March 16, 2001 1:49 PM To: DHCPv6 discussion list Subject: Client ID and DUID and variable within fixed bound Folks, On the design team there was some statements that the client-id + DUID would be variable. I have issues with variable after writing code for many years unless it is absolutely necessary. It complicates everything but I too have used it when it really made sense. Rather than bring this up at the meeting on Wednesday I thought I would try to get some discussion where people are coming from. Also variable within a bounded fixed-length as OSI NSAP address was in that protocol is at least a minimum requirement without serious justification. I would also state my gut feeling is that 128bits is more than enough for that fixed-length field based on old IPng and EID and to some degree NIMROD discussions days ago in the IETF for many years. Also for this we really need to think "mobile" wireless and its affect. And variable unbounded length fields cause optimizations and much variance in database and protocol datastructures. Anyway here is my belief of where we are with this IA DUID: 6 bytes - Hardware Address or possibly serial number 2 bytes - unique interface identifier the node keeps for each interface at the upper layer as it numbers them so it don't change 4 byte - timestamp 4 byte - TBD I am beginning to think the entire set of bytes is the DUID and the IA identifier? Can anyone state why we need more than 128bits? Discussion? thanks /jim ------_=_NextPart_001_01C0AE63.522CD8C0 Content-Type: text/html; charset="iso-8859-1" RE: Client ID and DUID and variable within fixed bound
Great.
 
Regarding identity id, are you referring to what goes into the Identity Association option?
That should be different. The client id needs to go into the ALL requests even if the client
isn't asking for addresses.
 
Reason is we need some way to identify the client that is making a request - such that a
server can:
a) Track what a client has. Since there are applications where you might want to restrict
that.
b) You have some useful and meaningful value by which to track who had an address when.
Just having a value that can constantly change doesn't buy you anything. Sure, you could
record the client link-local address but that is unique only to a link (prefix).
c) We need some id that we can use in the DHCID RR so that a single client is allowed to
register multiple addresses under one name. If the client always registers the forward (A6)
entry, then it could use some other identifier. However, if the server is doing it it needs
some way to know that the existing belongs to the same client.
d) If you want to do client specific reservations (either specific addresses or number of
addresses) OR want to give a specific client some set of configuration parameters
(perhaps other than addresses), you need something by which to identify that client.
 
Do you need more reasons?
 
- Bernie
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 4:41 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Bernie,
 
I said I can live with variable as long as there is upper limit (thats what OSI NSAP did).
I am less clear right now if identity id should be different than client-id.
I have no issue with your proposed fields at first glance.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday,March 16,2001 4:07 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Jim:

I don't have a problem with using a fixed identifer. Though, I
don't see it being variable is such a big deal (especially if
we set a reasonable upper limit).

I think the DUID should just be the CLIENT IDENTIFIER. So, I
would use something like:
- 2 bytes - Type field (how the DUID is constructed, such as
  using the EUI-64 has a different value than if a serial number
  is used to prevent collisions)
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp

The point is that a client thas ONE of this values and uses it
for all DHCP requests (regardless of which interface or how many
requests it is making).

In many ways, having this be a 128-bit quantity is kind of nice.
So, perhaps to increase the randomness of this, we use:
- 2 bytes - Typ field
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp
- 2 byte  - random number
Or, just specify the last 6 bytes as timestamp or other random
number.

What about running this through some short of hashing algorithm
(such as what's proposed for the DHCID RR?) to allow the hardware
address/serial number to be concealed (privacy concerns).

We put this DUID into the packets - I think it should go into the
header. But it could also be an option.

For the Identity Association, we use an IdentityID value that is
32 or 64 bits. This value is contructed by client and is opaque.

- Bernie

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 1:49 PM
To: DHCPv6 discussion list
Subject: Client ID and DUID and variable within fixed bound


Folks,

On the design team there was some statements that the client-id + DUID would
be variable.  I have issues with variable after writing code for many years
unless it is absolutely necessary.  It complicates everything but I too have
used it when it really made sense.  Rather than bring this up at the meeting
on Wednesday I thought I would try to get some discussion where people are
coming from.

Also variable within a bounded fixed-length as OSI NSAP address was in that
protocol is at least a minimum requirement without serious justification. I
would also state my gut feeling is that 128bits is more than enough for that
fixed-length field based on old IPng and EID and to some degree NIMROD
discussions days ago in the IETF for many years.

Also for this we really need to think "mobile" wireless and its affect.  And
variable unbounded length fields cause optimizations and much variance in
database and protocol datastructures.  Anyway here is my belief of where we
are with this IA DUID:

6 bytes - Hardware Address or possibly serial number
2 bytes - unique interface identifier the node keeps for each interface at
          the upper layer as it numbers them so it don't change
4 byte  - timestamp
4 byte  - TBD

I am beginning to think the entire set of bytes is the DUID and the IA
identifier?

Can anyone state why we need more than 128bits?

Discussion?

thanks
/jim

------_=_NextPart_001_01C0AE63.522CD8C0-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 17:12:38 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13997; Fri, 16 Mar 2001 17:12:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GMBmL09128; Fri, 16 Mar 2001 17:11:48 -0500 (EST) Received: from rdroms-w2k.bucknell.edu (sj-natpool-220.cisco.com [128.107.248.220]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GMBYL05509 for ; Fri, 16 Mar 2001 17:11:34 -0500 (EST) Message-Id: <4.3.2.7.2.20010316163616.03601148@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Mar 2001 17:11:06 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: why seperate Ia is needed for sending new Requests? In-Reply-To: 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 It's Friday afternoon, my wife's been visiting her mother in Wisconsin all week and I'm rushing around getting ready to go to Minneapolis - so I'm having trouble remembering the details about previous discussions about a version number in the DHCP message header. But it strikes me that we came to the conclusion that a version number turns out to be not all that useful. Does anyone else remember having this discussion previously - it might have been regarding DHCPv4? - Ralph At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: >I mean't to bring up the version number before. We were asked for this some >time ago and a suggestion from several. I can't recall arguments against it >and it may have fell through the cracks? > >/jim > > > -----Original Message----- > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com] > > Sent: Friday,March 16,2001 3:12 PM > > To: DHCPv6 discussion list > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > Hi, > > > > I would agree with what Jim is saying. The market > > is ready for DHCPv6 and we need some conclusion > > on this fast. > > > > At the same time there should be some scope for > > whatever the future versions to interoperate with > > the older ones. I would like to make 2 suggestions > > in this regard > > > > 1. To have an unimplemented error message. > > 2. To have a version field in the header. > > > > So that even if the IESG takes a long time to make > > a standard. We can proceed with the existing drafts, > > if the standard is different from the draft, we should > > be able to handle them easily. > > > > > > -ebi > > Hewlett-Packard > > 408-447-7652 > > > > ----- Original Message ----- > > From: > > To: DHCPv6 discussion list > > Sent: Friday, March 16, 2001 7:50 AM > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > hi ralph, > > > > > > I agree with you in spirit but the flesh is weak. we have > > chased the > > client > > > telling servers "I want x addresses" for a long time. I > > suggest as I > > do for > > > reconf-init multicast we not permit in our effort to get to PS. We > > will not > > > reach consensus and the market is ready for dhcp using ipv6. I also > > believe > > > reality is that most clients will get a default number of addresses > > from the > > > server. clients that send another IA will get x addresses as they > > will be > > > special anyway. So though in "theory" it seems messy, in practice I > > think > > > it will work fine. > > > > > > for temporary addresses I think the client setting a bit in > > IA Status > > will > > > tell the server I need to "note" temporary addresses. When the > > server > > > responds it will send x addresses to the client. Before > > each address > > a bit > > > will be set in the addr status field that this address is "noted" as > > > temporary. I really don't think temporary addresses is a complex > > thing and > > > I think we need to be careful we don't over complicate this part of > > what we > > > need to do. at the server for the T1,T2,Preferred, and Valid > > lifetimes the > > > server can apply the recommendations of rfc 3041 to the > > times it uses > > to > > > provide the client leases. Pretty simplex stuff I think. then we > > just need > > > to make a decision on whether we let server renew temporary > > addresses. in > > > the design call I think I heard it was ok to extend the valid > > lifetime but > > > not the preferred lifetime. I think we should be able to wrap this > > up at > > > minneapolis. > > > > > > what would be really useful for the wed dhcpv6 venue is if ted could > > provide > > > the format and datum picture of the IA + client-id parts for the IA > > option > > > and the text for forming it so we can discuss. That is necessary to > > go to > > > last call. I think this is the most important and critical item we > > work on > > > next week. > > > > > > thanks > > > > > > /jim > > > > > > > -----Original Message----- > > > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > To: DHCPv6 discussion list > > > > Cc: DHCPv6 discussion list > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > virtual web servers > > > > in the past. Based on the capabilities of the current > > > > version of HTTP for > > > > identifying virtual web servers behind a single IP address, > > > > we've discarded > > > > virtual web servers as a motivation for on-demand address > > assignment. > > > > > > > > That's not to say there aren't other motivations for > > > > on-demand address > > > > assignment. Perhaps temporary addresses are a good > > > > motivating example. If > > > > we're going to add complexity to the protocol to support > > > > on-demand address > > > > assignment, we need to make sure we understand the specific > > > > motivations and > > > > requirements. > > > > > > > > - Ralph > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > >It is entirely possible for a client to ask for more > > > > "normal" addresses. > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > in IPv6 it wont > > > > >be. A server that does web hosting may need thousands of IP > > > > addresses and > > > > >it may not be possible to know the requirement ahead of time > > > > in all cases. > > > > >It will contact the DHCP Server to request more IP addresses > > > > in this case > > > > >or use stateless config to generate the IPs it needs. A > > > > server hosting > > > > >different services may want to use different "normal" > > > > addresses for each > > > > >service. > > > > > > > > > > > > > > > > > From owner-dhcp-v6@bucknell.edu Fri Mar 16 17:44:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14314; Fri, 16 Mar 2001 17:44:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GMg3L16666; Fri, 16 Mar 2001 17:42:03 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2GMfrL09695 for ; Fri, 16 Mar 2001 17:41:53 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2GMfqm28267 for ; Fri, 16 Mar 2001 16:41:52 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2GMfpT04659 for ; Fri, 16 Mar 2001 16:41:52 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Mar 16 16:41:13 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 16:42:58 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB868@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 16:42:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE6A.6D588CA0" 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 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_001_01C0AE6A.6D588CA0 Content-Type: text/plain; charset="iso-8859-1" Ralph: Wish I could remember the details as well. I think one argument might be that why not just change the UDP port number if you revise the protocol? Another is that by using a version number, you might not gain that much because at least part of the message format must stay the same in order to be able to recognize that this is a new version of the protocol. And, a third possiblity is that since the message type is the first byte, why not just use new message types? And, forth, future revisions of the protocol could be handled by sending a special option on the Advertise or Solicit to indicate that the server is capable of the extended functionality. Though in this case, the basic message format has to be retained. BTW: Regarding the error message issue, how about we have a message type which can be sent by a agent (server or relay) to respond to a client to return some error. That way, if the client sends an unknown message type, the server (or relay) can respond. This message type MUST be unicast by the relay or server. That message type might be formatted as follows: 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 | error-number | error-text | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Probably the only error number that is needed today is "unknown/unimplemented message type"? - Bernie -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Friday, March 16, 2001 5:11 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? It's Friday afternoon, my wife's been visiting her mother in Wisconsin all week and I'm rushing around getting ready to go to Minneapolis - so I'm having trouble remembering the details about previous discussions about a version number in the DHCP message header. But it strikes me that we came to the conclusion that a version number turns out to be not all that useful. Does anyone else remember having this discussion previously - it might have been regarding DHCPv4? - Ralph At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: >I mean't to bring up the version number before. We were asked for this some >time ago and a suggestion from several. I can't recall arguments against it >and it may have fell through the cracks? > >/jim > > > -----Original Message----- > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com] > > Sent: Friday,March 16,2001 3:12 PM > > To: DHCPv6 discussion list > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > Hi, > > > > I would agree with what Jim is saying. The market > > is ready for DHCPv6 and we need some conclusion > > on this fast. > > > > At the same time there should be some scope for > > whatever the future versions to interoperate with > > the older ones. I would like to make 2 suggestions > > in this regard > > > > 1. To have an unimplemented error message. > > 2. To have a version field in the header. > > > > So that even if the IESG takes a long time to make > > a standard. We can proceed with the existing drafts, > > if the standard is different from the draft, we should > > be able to handle them easily. > > > > > > -ebi > > Hewlett-Packard > > 408-447-7652 > > > > ----- Original Message ----- > > From: > > To: DHCPv6 discussion list > > Sent: Friday, March 16, 2001 7:50 AM > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > hi ralph, > > > > > > I agree with you in spirit but the flesh is weak. we have > > chased the > > client > > > telling servers "I want x addresses" for a long time. I > > suggest as I > > do for > > > reconf-init multicast we not permit in our effort to get to PS. We > > will not > > > reach consensus and the market is ready for dhcp using ipv6. I also > > believe > > > reality is that most clients will get a default number of addresses > > from the > > > server. clients that send another IA will get x addresses as they > > will be > > > special anyway. So though in "theory" it seems messy, in practice I > > think > > > it will work fine. > > > > > > for temporary addresses I think the client setting a bit in > > IA Status > > will > > > tell the server I need to "note" temporary addresses. When the > > server > > > responds it will send x addresses to the client. Before > > each address > > a bit > > > will be set in the addr status field that this address is "noted" as > > > temporary. I really don't think temporary addresses is a complex > > thing and > > > I think we need to be careful we don't over complicate this part of > > what we > > > need to do. at the server for the T1,T2,Preferred, and Valid > > lifetimes the > > > server can apply the recommendations of rfc 3041 to the > > times it uses > > to > > > provide the client leases. Pretty simplex stuff I think. then we > > just need > > > to make a decision on whether we let server renew temporary > > addresses. in > > > the design call I think I heard it was ok to extend the valid > > lifetime but > > > not the preferred lifetime. I think we should be able to wrap this > > up at > > > minneapolis. > > > > > > what would be really useful for the wed dhcpv6 venue is if ted could > > provide > > > the format and datum picture of the IA + client-id parts for the IA > > option > > > and the text for forming it so we can discuss. That is necessary to > > go to > > > last call. I think this is the most important and critical item we > > work on > > > next week. > > > > > > thanks > > > > > > /jim > > > > > > > -----Original Message----- > > > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > To: DHCPv6 discussion list > > > > Cc: DHCPv6 discussion list > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > virtual web servers > > > > in the past. Based on the capabilities of the current > > > > version of HTTP for > > > > identifying virtual web servers behind a single IP address, > > > > we've discarded > > > > virtual web servers as a motivation for on-demand address > > assignment. > > > > > > > > That's not to say there aren't other motivations for > > > > on-demand address > > > > assignment. Perhaps temporary addresses are a good > > > > motivating example. If > > > > we're going to add complexity to the protocol to support > > > > on-demand address > > > > assignment, we need to make sure we understand the specific > > > > motivations and > > > > requirements. > > > > > > > > - Ralph > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > >It is entirely possible for a client to ask for more > > > > "normal" addresses. > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > in IPv6 it wont > > > > >be. A server that does web hosting may need thousands of IP > > > > addresses and > > > > >it may not be possible to know the requirement ahead of time > > > > in all cases. > > > > >It will contact the DHCP Server to request more IP addresses > > > > in this case > > > > >or use stateless config to generate the IPs it needs. A > > > > server hosting > > > > >different services may want to use different "normal" > > > > addresses for each > > > > >service. > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0AE6A.6D588CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?

Ralph:

Wish I could remember the details as well.

I think one argument might be that why not just = change the UDP port number if you revise the protocol?

Another is that by using a version number, you might = not gain that much because at least part of the message format must = stay the same in order to be able to recognize that this is a new = version of the protocol.

And, a third possiblity is that since the message = type is the first byte, why not just use new message types?

And, forth, future revisions of the protocol could be = handled by sending a special option on the Advertise or Solicit to = indicate that the server is capable of the extended functionality. = Though in this case, the basic message format has to be = retained.

BTW: Regarding the error message issue, how about we = have a message type which can be sent by a agent (server or relay) to = respond to a client to return some error. That way, if the client sends = an unknown message type, the server (or relay) can respond. This = message type MUST be unicast by the relay or server. That message type = might be formatted as follows:

      = 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   |  error-number = |      = error-text          &n= bsp;    |
     = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
     = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
     = |            = ;            = ;            = ;            = ;            = ;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Probably the only error number that is needed today = is "unknown/unimplemented message type"?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]=
Sent: Friday, March 16, 2001 5:11 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending = new Requests?


It's Friday afternoon, my wife's been visiting her = mother in Wisconsin all
week and I'm rushing around getting ready to go to = Minneapolis - so I'm
having trouble remembering the details about = previous discussions about a
version number in the DHCP message header.

But it strikes me that we came to the conclusion that = a version number
turns out to be not all that useful.  Does = anyone else remember having this
discussion previously - it might have been regarding = DHCPv4?

- Ralph

At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com = wrote:
>I mean't to bring up the version number = before.  We were asked for this some
>time ago and a suggestion from several.  I = can't recall arguments against it
>and it may have fell through the cracks?
>
>/jim
>
> > -----Original Message-----
> > From: ext ebenezer schubert [mailto:ebi@cup.hp.com]
> > Sent: Friday,March 16,2001 3:12 PM
> > To: DHCPv6 discussion list
> > Subject: Re: why seperate Ia is needed for = sending new Requests?
> >
> >
> > Hi,
> >
> >     I would agree with = what Jim is saying. The market
> >     is ready for = DHCPv6 and we need some conclusion
> >     on this = fast.
> >
> >    At the same time there = should be some scope for
> >    whatever the future = versions to interoperate with
> >    the older ones. I would = like to make 2 suggestions
> >    in this regard
> >
> >     1. To have an = unimplemented error message.
> >     2. To have a = version field in the header.
> >
> >    So that even if the IESG = takes a long time to make
> >    a standard. We can = proceed with the existing drafts,
> >    if the standard is = different from the draft, we should
> >    be able to handle them = easily.
> >
> >
> > -ebi
> > Hewlett-Packard
> > 408-447-7652
> >
> > ----- Original Message -----
> > From: <Jim.Bound@nokia.com>
> > To: DHCPv6 discussion list = <dhcp-v6@bucknell.edu>
> > Sent: Friday, March 16, 2001 7:50 = AM
> > Subject: RE: why seperate Ia is needed for = sending new Requests?
> >
> >
> > > hi ralph,
> > >
> > > I agree with you in spirit but the = flesh is weak.  we have
> > chased the
> > client
> > > telling servers "I want x = addresses" for a long time.  I
> > suggest as I
> > do for
> > > reconf-init multicast we not permit = in our effort to get to PS.  We
> > will not
> > > reach consensus and the market is = ready for dhcp using ipv6. I also
> > believe
> > > reality is that most clients will get = a default number of addresses
> > from the
> > > server.  clients that send = another IA will get x addresses as they
> > will be
> > > special anyway.  So though in = "theory" it seems messy, in practice I
> > think
> > > it will work fine.
> > >
> > > for temporary addresses I think the = client setting a bit in
> > IA Status
> > will
> > > tell the server I need to = "note" temporary addresses.  When the
> > server
> > > responds it will send x addresses to = the client.  Before
> > each address
> > a bit
> > > will be set in the addr status field = that this address is "noted" as
> > > temporary.  I really don't think = temporary addresses is a complex
> > thing and
> > > I think we need to be careful we = don't over complicate this part of
> > what we
> > > need to do.  at the server for = the T1,T2,Preferred, and Valid
> > lifetimes the
> > > server can apply the recommendations = of rfc 3041 to the
> > times it uses
> > to
> > > provide the client leases.  = Pretty simplex stuff I think.  then we
> > just need
> > > to make a decision on whether we let = server renew temporary
> > addresses.  in
> > > the design call I think I heard it = was ok to extend the valid
> > lifetime but
> > > not the preferred lifetime.  I = think we should be able to wrap this
> > up at
> > > minneapolis.
> > >
> > > what would be really useful for the = wed dhcpv6 venue is if ted could
> > provide
> > > the format and datum picture of the = IA + client-id parts for the IA
> > option
> > > and the text for forming it so we can = discuss.  That is necessary to
> > go to
> > > last call.  I think this is the = most important and critical item we
> > work on
> > > next week.
> > >
> > > thanks
> > >
> > > /jim
> > >
> > > > -----Original = Message-----
> > > > From: ext Ralph Droms [mailto:rdroms@cisco.com]
> > > > Sent: Thursday,March 15,2001 = 7:57 PM
> > > > To: DHCPv6 discussion = list
> > > > Cc: DHCPv6 discussion = list
> > > > Subject: RE: why seperate Ia is = needed for sending new Requests?
> > > >
> > > >
> > > > If I remember correctly, we've = considered the issue of
> > > > virtual web servers
> > > > in the past.  Based on the = capabilities of the current
> > > > version of HTTP for
> > > > identifying virtual web servers = behind a single IP address,
> > > > we've discarded
> > > > virtual web servers as a = motivation for on-demand address
> > assignment.
> > > >
> > > > That's not to say there aren't = other motivations for
> > > > on-demand address
> > > > assignment.  Perhaps = temporary addresses are a good
> > > > motivating example.  = If
> > > > we're going to add complexity to = the protocol to support
> > > > on-demand address
> > > > assignment, we need to make sure = we understand the specific
> > > > motivations and
> > > > requirements.
> > > >
> > > > - Ralph
> > > >
> > > > At 07:31 AM 3/15/2001 -0800, = Thirumalesh Bhat wrote:
> > > > >It is entirely possible for = a client to ask for more
> > > > "normal" = addresses.
> > > > >The reason being in IPv4, = addresses were a bottle neck and
> > > > in IPv6 it wont
> > > > >be. A server that does web = hosting may need thousands of IP
> > > > addresses and
> > > > >it may not be possible to = know the requirement ahead of time
> > > > in all cases.
> > > > >It will contact the DHCP = Server to request more IP addresses
> > > > in this case
> > > > >or use stateless config to = generate the IPs it needs. A
> > > > server hosting
> > > > >different services may want = to use different "normal"
> > > > addresses for each
> > > > >service.
> > > >
> > > >
> > > >
> > >
> >

------_=_NextPart_001_01C0AE6A.6D588CA0-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 18:10:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14717; Fri, 16 Mar 2001 18:10:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2GN9iL01955; Fri, 16 Mar 2001 18:09:44 -0500 (EST) 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 f2GN9dL27202 for ; Fri, 16 Mar 2001 18:09:40 -0500 (EST) Received: from hpindbm.cup.hp.com (hpindbm.cup.hp.com [15.13.104.188]) by palrel3.hp.com (Postfix) with ESMTP id 2787FC26 for ; Fri, 16 Mar 2001 15:09:39 -0800 (PST) Received: (from ebi@localhost) by hpindbm.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA22100 for dhcp-v6@bucknell.edu; Fri, 16 Mar 2001 15:09:38 -0800 (PST) From: Ebenezer Schubert Message-Id: <200103162309.PAA22100@hpindbm.cup.hp.com> Subject: Re: why seperate Ia is needed for sending new Requests? To: DHCPv6 discussion list Date: Fri, 16 Mar 2001 15:09:38 -0800 (PST) In-Reply-To: <66F66129A77AD411B76200508B65AC694CB868@eambunt705.ena-east.ericsson.se> from Bernie Volz at Mar "16," 2001 "04:42:49" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Hi, As long as there is an agreement that any new functionality starting from draft revision xxxx, there would be no changes to the msg structure or the interpretation of existing message types and any new feature would be through the introduction of a new message type. Then it is ok. But right now, there seems to be a lot of changes. So having a version no. field, can help to start the development activity parallel to the work in the IETF. This is the reason why revising the protocol port no. would not make any sense, because we may not be able to change port nos, between different versions of the draft. Also, we cannot gurantee, that the interpretation of a particular message type will not change until this becomes an RFC. -ebi > Ralph: > > Wish I could remember the details as well. > > I think one argument might be that why not just change the UDP port number if you revise the protocol? > > Another is that by using a version number, you might not gain that much because at least part of the message format must stay the same in order to be able to recognize that this is a new version of the protocol. > > And, a third possiblity is that since the message type is the first byte, why not just use new message types? > > And, forth, future revisions of the protocol could be handled by sending a special option on the Advertise or Solicit to indicate that the server is capable of the extended functionality. Though in this case, the basic message format has to be retained. > > BTW: Regarding the error message issue, how about we have a message type which can be sent by a agent (server or relay) to respond to a client to return some error. That way, if the client sends an unknown message type, the server (or relay) can respond. This message type MUST be unicast by the relay or server. That message type might be formatted as follows: > > 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 | error-number | error-text | > . . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Probably the only error number that is needed today is "unknown/unimplemented message type"? > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:droms@bucknell.edu] > Sent: Friday, March 16, 2001 5:11 PM > To: DHCPv6 discussion list > Subject: RE: why seperate Ia is needed for sending new Requests? > > > It's Friday afternoon, my wife's been visiting her mother in Wisconsin all > week and I'm rushing around getting ready to go to Minneapolis - so I'm > having trouble remembering the details about previous discussions about a > version number in the DHCP message header. > > But it strikes me that we came to the conclusion that a version number > turns out to be not all that useful. Does anyone else remember having this > discussion previously - it might have been regarding DHCPv4? > > - Ralph > > At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: > >I mean't to bring up the version number before. We were asked for this some > >time ago and a suggestion from several. I can't recall arguments against it > >and it may have fell through the cracks? > > > >/jim > > > > > -----Original Message----- > > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com] > > > Sent: Friday,March 16,2001 3:12 PM > > > To: DHCPv6 discussion list > > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > > > > Hi, > > > > > > I would agree with what Jim is saying. The market > > > is ready for DHCPv6 and we need some conclusion > > > on this fast. > > > > > > At the same time there should be some scope for > > > whatever the future versions to interoperate with > > > the older ones. I would like to make 2 suggestions > > > in this regard > > > > > > 1. To have an unimplemented error message. > > > 2. To have a version field in the header. > > > > > > So that even if the IESG takes a long time to make > > > a standard. We can proceed with the existing drafts, > > > if the standard is different from the draft, we should > > > be able to handle them easily. > > > > > > > > > -ebi > > > Hewlett-Packard > > > 408-447-7652 > > > > > > ----- Original Message ----- > > > From: > > > To: DHCPv6 discussion list > > > Sent: Friday, March 16, 2001 7:50 AM > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > hi ralph, > > > > > > > > I agree with you in spirit but the flesh is weak. we have > > > chased the > > > client > > > > telling servers "I want x addresses" for a long time. I > > > suggest as I > > > do for > > > > reconf-init multicast we not permit in our effort to get to PS. We > > > will not > > > > reach consensus and the market is ready for dhcp using ipv6. I also > > > believe > > > > reality is that most clients will get a default number of addresses > > > from the > > > > server. clients that send another IA will get x addresses as they > > > will be > > > > special anyway. So though in "theory" it seems messy, in practice I > > > think > > > > it will work fine. > > > > > > > > for temporary addresses I think the client setting a bit in > > > IA Status > > > will > > > > tell the server I need to "note" temporary addresses. When the > > > server > > > > responds it will send x addresses to the client. Before > > > each address > > > a bit > > > > will be set in the addr status field that this address is "noted" as > > > > temporary. I really don't think temporary addresses is a complex > > > thing and > > > > I think we need to be careful we don't over complicate this part of > > > what we > > > > need to do. at the server for the T1,T2,Preferred, and Valid > > > lifetimes the > > > > server can apply the recommendations of rfc 3041 to the > > > times it uses > > > to > > > > provide the client leases. Pretty simplex stuff I think. then we > > > just need > > > > to make a decision on whether we let server renew temporary > > > addresses. in > > > > the design call I think I heard it was ok to extend the valid > > > lifetime but > > > > not the preferred lifetime. I think we should be able to wrap this > > > up at > > > > minneapolis. > > > > > > > > what would be really useful for the wed dhcpv6 venue is if ted could > > > provide > > > > the format and datum picture of the IA + client-id parts for the IA > > > option > > > > and the text for forming it so we can discuss. That is necessary to > > > go to > > > > last call. I think this is the most important and critical item we > > > work on > > > > next week. > > > > > > > > thanks > > > > > > > > /jim > > > > > > > > > -----Original Message----- > > > > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > > To: DHCPv6 discussion list > > > > > Cc: DHCPv6 discussion list > > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > > virtual web servers > > > > > in the past. Based on the capabilities of the current > > > > > version of HTTP for > > > > > identifying virtual web servers behind a single IP address, > > > > > we've discarded > > > > > virtual web servers as a motivation for on-demand address > > > assignment. > > > > > > > > > > That's not to say there aren't other motivations for > > > > > on-demand address > > > > > assignment. Perhaps temporary addresses are a good > > > > > motivating example. If > > > > > we're going to add complexity to the protocol to support > > > > > on-demand address > > > > > assignment, we need to make sure we understand the specific > > > > > motivations and > > > > > requirements. > > > > > > > > > > - Ralph > > > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > > >It is entirely possible for a client to ask for more > > > > > "normal" addresses. > > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > > in IPv6 it wont > > > > > >be. A server that does web hosting may need thousands of IP > > > > > addresses and > > > > > >it may not be possible to know the requirement ahead of time > > > > > in all cases. > > > > > >It will contact the DHCP Server to request more IP addresses > > > > > in this case > > > > > >or use stateless config to generate the IPs it needs. A > > > > > server hosting > > > > > >different services may want to use different "normal" > > > > > addresses for each > > > > > >service. > > > > > > > > > > > > > > > > > > > > > > From owner-dhcp-v6@bucknell.edu Fri Mar 16 23:42:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20324; Fri, 16 Mar 2001 23:42:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2H4dqL04913; Fri, 16 Mar 2001 23:39:52 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2H4dbL03294 for ; Fri, 16 Mar 2001 23:39:37 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2H4dJg00642 for ; Fri, 16 Mar 2001 22:39:29 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 22:39:16 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 22:39:16 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Date: Fri, 16 Mar 2001 22:39:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE9C.38FB2C10" 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 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_001_01C0AE9C.38FB2C10 Content-Type: text/plain; charset="iso-8859-1" understand the reason why we need to identify a client never did have issue with that. still not sure we need IA and Client ID. If a node can have multiple client IDs. the only reason a server needs to know about a client is because of addresses. everything else is "inform". to say we need it because we "believe it" is weak. if we follow that logic then all the folks who wanted the client to request addresses provided much strong arguments and we told them no. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday,March 16,2001 4:52 PM To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Great. Regarding identity id, are you referring to what goes into the Identity Association option? That should be different. The client id needs to go into the ALL requests even if the client isn't asking for addresses. Reason is we need some way to identify the client that is making a request - such that a server can: a) Track what a client has. Since there are applications where you might want to restrict that. b) You have some useful and meaningful value by which to track who had an address when. Just having a value that can constantly change doesn't buy you anything. Sure, you could record the client link-local address but that is unique only to a link (prefix). c) We need some id that we can use in the DHCID RR so that a single client is allowed to register multiple addresses under one name. If the client always registers the forward (A6) entry, then it could use some other identifier. However, if the server is doing it it needs some way to know that the existing belongs to the same client. d) If you want to do client specific reservations (either specific addresses or number of addresses) OR want to give a specific client some set of configuration parameters (perhaps other than addresses), you need something by which to identify that client. Do you need more reasons? - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 4:41 PM To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Bernie, I said I can live with variable as long as there is upper limit (thats what OSI NSAP did). I am less clear right now if identity id should be different than client-id. I have no issue with your proposed fields at first glance. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday,March 16,2001 4:07 PM To: DHCPv6 discussion list Subject: RE: Client ID and DUID and variable within fixed bound Jim: I don't have a problem with using a fixed identifer. Though, I don't see it being variable is such a big deal (especially if we set a reasonable upper limit). I think the DUID should just be the CLIENT IDENTIFIER. So, I would use something like: - 2 bytes - Type field (how the DUID is constructed, such as using the EUI-64 has a different value than if a serial number is used to prevent collisions) - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp The point is that a client thas ONE of this values and uses it for all DHCP requests (regardless of which interface or how many requests it is making). In many ways, having this be a 128-bit quantity is kind of nice. So, perhaps to increase the randomness of this, we use: - 2 bytes - Typ field - 8 bytes - Hardware Address (EUI-64) or possibly serial number - 4 byte - timestamp - 2 byte - random number Or, just specify the last 6 bytes as timestamp or other random number. What about running this through some short of hashing algorithm (such as what's proposed for the DHCID RR?) to allow the hardware address/serial number to be concealed (privacy concerns). We put this DUID into the packets - I think it should go into the header. But it could also be an option. For the Identity Association, we use an IdentityID value that is 32 or 64 bits. This value is contructed by client and is opaque. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [ mailto:Jim.Bound@nokia.com ] Sent: Friday, March 16, 2001 1:49 PM To: DHCPv6 discussion list Subject: Client ID and DUID and variable within fixed bound Folks, On the design team there was some statements that the client-id + DUID would be variable. I have issues with variable after writing code for many years unless it is absolutely necessary. It complicates everything but I too have used it when it really made sense. Rather than bring this up at the meeting on Wednesday I thought I would try to get some discussion where people are coming from. Also variable within a bounded fixed-length as OSI NSAP address was in that protocol is at least a minimum requirement without serious justification. I would also state my gut feeling is that 128bits is more than enough for that fixed-length field based on old IPng and EID and to some degree NIMROD discussions days ago in the IETF for many years. Also for this we really need to think "mobile" wireless and its affect. And variable unbounded length fields cause optimizations and much variance in database and protocol datastructures. Anyway here is my belief of where we are with this IA DUID: 6 bytes - Hardware Address or possibly serial number 2 bytes - unique interface identifier the node keeps for each interface at the upper layer as it numbers them so it don't change 4 byte - timestamp 4 byte - TBD I am beginning to think the entire set of bytes is the DUID and the IA identifier? Can anyone state why we need more than 128bits? Discussion? thanks /jim ------_=_NextPart_001_01C0AE9C.38FB2C10 Content-Type: text/html; charset="iso-8859-1" RE: Client ID and DUID and variable within fixed bound
understand the reason why we need to identify a client never did have issue with that.
still not sure we need IA and Client ID.  If a node can have multiple client IDs.  the only reason a server needs to know about a client is because of addresses.  everything else is "inform".
 
to say we need it because we "believe it" is weak.  if we follow that logic then all the folks who wanted the client to request addresses provided much strong arguments and we told them no.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday,March 16,2001 4:52 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Great.
 
Regarding identity id, are you referring to what goes into the Identity Association option?
That should be different. The client id needs to go into the ALL requests even if the client
isn't asking for addresses.
 
Reason is we need some way to identify the client that is making a request - such that a
server can:
a) Track what a client has. Since there are applications where you might want to restrict
that.
b) You have some useful and meaningful value by which to track who had an address when.
Just having a value that can constantly change doesn't buy you anything. Sure, you could
record the client link-local address but that is unique only to a link (prefix).
c) We need some id that we can use in the DHCID RR so that a single client is allowed to
register multiple addresses under one name. If the client always registers the forward (A6)
entry, then it could use some other identifier. However, if the server is doing it it needs
some way to know that the existing belongs to the same client.
d) If you want to do client specific reservations (either specific addresses or number of
addresses) OR want to give a specific client some set of configuration parameters
(perhaps other than addresses), you need something by which to identify that client.
 
Do you need more reasons?
 
- Bernie
-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 4:41 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Bernie,
 
I said I can live with variable as long as there is upper limit (thats what OSI NSAP did).
I am less clear right now if identity id should be different than client-id.
I have no issue with your proposed fields at first glance.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday,March 16,2001 4:07 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Jim:

I don't have a problem with using a fixed identifer. Though, I
don't see it being variable is such a big deal (especially if
we set a reasonable upper limit).

I think the DUID should just be the CLIENT IDENTIFIER. So, I
would use something like:
- 2 bytes - Type field (how the DUID is constructed, such as
  using the EUI-64 has a different value than if a serial number
  is used to prevent collisions)
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp

The point is that a client thas ONE of this values and uses it
for all DHCP requests (regardless of which interface or how many
requests it is making).

In many ways, having this be a 128-bit quantity is kind of nice.
So, perhaps to increase the randomness of this, we use:
- 2 bytes - Typ field
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp
- 2 byte  - random number
Or, just specify the last 6 bytes as timestamp or other random
number.

What about running this through some short of hashing algorithm
(such as what's proposed for the DHCID RR?) to allow the hardware
address/serial number to be concealed (privacy concerns).

We put this DUID into the packets - I think it should go into the
header. But it could also be an option.

For the Identity Association, we use an IdentityID value that is
32 or 64 bits. This value is contructed by client and is opaque.

- Bernie

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 1:49 PM
To: DHCPv6 discussion list
Subject: Client ID and DUID and variable within fixed bound


Folks,

On the design team there was some statements that the client-id + DUID would
be variable.  I have issues with variable after writing code for many years
unless it is absolutely necessary.  It complicates everything but I too have
used it when it really made sense.  Rather than bring this up at the meeting
on Wednesday I thought I would try to get some discussion where people are
coming from.

Also variable within a bounded fixed-length as OSI NSAP address was in that
protocol is at least a minimum requirement without serious justification. I
would also state my gut feeling is that 128bits is more than enough for that
fixed-length field based on old IPng and EID and to some degree NIMROD
discussions days ago in the IETF for many years.

Also for this we really need to think "mobile" wireless and its affect.  And
variable unbounded length fields cause optimizations and much variance in
database and protocol datastructures.  Anyway here is my belief of where we
are with this IA DUID:

6 bytes - Hardware Address or possibly serial number
2 bytes - unique interface identifier the node keeps for each interface at
          the upper layer as it numbers them so it don't change
4 byte  - timestamp
4 byte  - TBD

I am beginning to think the entire set of bytes is the DUID and the IA
identifier?

Can anyone state why we need more than 128bits?

Discussion?

thanks
/jim

------_=_NextPart_001_01C0AE9C.38FB2C10-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 23:45:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20349; Fri, 16 Mar 2001 23:45:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2H4iaL14168; Fri, 16 Mar 2001 23:44:36 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2H4iVL10000 for ; Fri, 16 Mar 2001 23:44:32 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2H4iXg00659 for ; Fri, 16 Mar 2001 22:44:33 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 22:44:31 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 22:44:30 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 22:44:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE9C.F3C46700" 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 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_001_01C0AE9C.F3C46700 Content-Type: text/plain; charset="iso-8859-1" mike carney was one who wanted the version number. issue was client implementations at bake-offs and in practice would break for a long time when new features were added. I don't think we need it just don't want it to pop up at the last minute. but if folks want it I can see a use for it too. so I am agnostic on the issue. but would like to end that loose end if it exists one way or the other. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday,March 16,2001 5:43 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Ralph: Wish I could remember the details as well. I think one argument might be that why not just change the UDP port number if you revise the protocol? Another is that by using a version number, you might not gain that much because at least part of the message format must stay the same in order to be able to recognize that this is a new version of the protocol. And, a third possiblity is that since the message type is the first byte, why not just use new message types? And, forth, future revisions of the protocol could be handled by sending a special option on the Advertise or Solicit to indicate that the server is capable of the extended functionality. Though in this case, the basic message format has to be retained. BTW: Regarding the error message issue, how about we have a message type which can be sent by a agent (server or relay) to respond to a client to return some error. That way, if the client sends an unknown message type, the server (or relay) can respond. This message type MUST be unicast by the relay or server. That message type might be formatted as follows: 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 | error-number | error-text | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Probably the only error number that is needed today is "unknown/unimplemented message type"? - Bernie -----Original Message----- From: Ralph Droms [ mailto:droms@bucknell.edu ] Sent: Friday, March 16, 2001 5:11 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? It's Friday afternoon, my wife's been visiting her mother in Wisconsin all week and I'm rushing around getting ready to go to Minneapolis - so I'm having trouble remembering the details about previous discussions about a version number in the DHCP message header. But it strikes me that we came to the conclusion that a version number turns out to be not all that useful. Does anyone else remember having this discussion previously - it might have been regarding DHCPv4? - Ralph At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: >I mean't to bring up the version number before. We were asked for this some >time ago and a suggestion from several. I can't recall arguments against it >and it may have fell through the cracks? > >/jim > > > -----Original Message----- > > From: ext ebenezer schubert [ mailto:ebi@cup.hp.com ] > > Sent: Friday,March 16,2001 3:12 PM > > To: DHCPv6 discussion list > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > Hi, > > > > I would agree with what Jim is saying. The market > > is ready for DHCPv6 and we need some conclusion > > on this fast. > > > > At the same time there should be some scope for > > whatever the future versions to interoperate with > > the older ones. I would like to make 2 suggestions > > in this regard > > > > 1. To have an unimplemented error message. > > 2. To have a version field in the header. > > > > So that even if the IESG takes a long time to make > > a standard. We can proceed with the existing drafts, > > if the standard is different from the draft, we should > > be able to handle them easily. > > > > > > -ebi > > Hewlett-Packard > > 408-447-7652 > > > > ----- Original Message ----- > > From: > > To: DHCPv6 discussion list > > Sent: Friday, March 16, 2001 7:50 AM > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > hi ralph, > > > > > > I agree with you in spirit but the flesh is weak. we have > > chased the > > client > > > telling servers "I want x addresses" for a long time. I > > suggest as I > > do for > > > reconf-init multicast we not permit in our effort to get to PS. We > > will not > > > reach consensus and the market is ready for dhcp using ipv6. I also > > believe > > > reality is that most clients will get a default number of addresses > > from the > > > server. clients that send another IA will get x addresses as they > > will be > > > special anyway. So though in "theory" it seems messy, in practice I > > think > > > it will work fine. > > > > > > for temporary addresses I think the client setting a bit in > > IA Status > > will > > > tell the server I need to "note" temporary addresses. When the > > server > > > responds it will send x addresses to the client. Before > > each address > > a bit > > > will be set in the addr status field that this address is "noted" as > > > temporary. I really don't think temporary addresses is a complex > > thing and > > > I think we need to be careful we don't over complicate this part of > > what we > > > need to do. at the server for the T1,T2,Preferred, and Valid > > lifetimes the > > > server can apply the recommendations of rfc 3041 to the > > times it uses > > to > > > provide the client leases. Pretty simplex stuff I think. then we > > just need > > > to make a decision on whether we let server renew temporary > > addresses. in > > > the design call I think I heard it was ok to extend the valid > > lifetime but > > > not the preferred lifetime. I think we should be able to wrap this > > up at > > > minneapolis. > > > > > > what would be really useful for the wed dhcpv6 venue is if ted could > > provide > > > the format and datum picture of the IA + client-id parts for the IA > > option > > > and the text for forming it so we can discuss. That is necessary to > > go to > > > last call. I think this is the most important and critical item we > > work on > > > next week. > > > > > > thanks > > > > > > /jim > > > > > > > -----Original Message----- > > > > From: ext Ralph Droms [ mailto:rdroms@cisco.com ] > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > To: DHCPv6 discussion list > > > > Cc: DHCPv6 discussion list > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > virtual web servers > > > > in the past. Based on the capabilities of the current > > > > version of HTTP for > > > > identifying virtual web servers behind a single IP address, > > > > we've discarded > > > > virtual web servers as a motivation for on-demand address > > assignment. > > > > > > > > That's not to say there aren't other motivations for > > > > on-demand address > > > > assignment. Perhaps temporary addresses are a good > > > > motivating example. If > > > > we're going to add complexity to the protocol to support > > > > on-demand address > > > > assignment, we need to make sure we understand the specific > > > > motivations and > > > > requirements. > > > > > > > > - Ralph > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > >It is entirely possible for a client to ask for more > > > > "normal" addresses. > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > in IPv6 it wont > > > > >be. A server that does web hosting may need thousands of IP > > > > addresses and > > > > >it may not be possible to know the requirement ahead of time > > > > in all cases. > > > > >It will contact the DHCP Server to request more IP addresses > > > > in this case > > > > >or use stateless config to generate the IPs it needs. A > > > > server hosting > > > > >different services may want to use different "normal" > > > > addresses for each > > > > >service. > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0AE9C.F3C46700 Content-Type: text/html; charset="iso-8859-1" RE: why seperate Ia is needed for sending new Requests?
mike carney was one who wanted the version number.  issue was client implementations at bake-offs and in practice would break for a long time when new features were added. 
 
I don't think we need it just don't want it to pop up at the last minute.  but if folks want it I can see a use for it too.  so I am agnostic on the issue.  but would like to end that loose end if it exists one way or the other.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday,March 16,2001 5:43 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Ralph:

Wish I could remember the details as well.

I think one argument might be that why not just change the UDP port number if you revise the protocol?

Another is that by using a version number, you might not gain that much because at least part of the message format must stay the same in order to be able to recognize that this is a new version of the protocol.

And, a third possiblity is that since the message type is the first byte, why not just use new message types?

And, forth, future revisions of the protocol could be handled by sending a special option on the Advertise or Solicit to indicate that the server is capable of the extended functionality. Though in this case, the basic message format has to be retained.

BTW: Regarding the error message issue, how about we have a message type which can be sent by a agent (server or relay) to respond to a client to return some error. That way, if the client sends an unknown message type, the server (or relay) can respond. This message type MUST be unicast by the relay or server. That message type might be formatted as follows:

      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   |  error-number |      error-text               |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Probably the only error number that is needed today is "unknown/unimplemented message type"?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Friday, March 16, 2001 5:11 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?


It's Friday afternoon, my wife's been visiting her mother in Wisconsin all
week and I'm rushing around getting ready to go to Minneapolis - so I'm
having trouble remembering the details about previous discussions about a
version number in the DHCP message header.

But it strikes me that we came to the conclusion that a version number
turns out to be not all that useful.  Does anyone else remember having this
discussion previously - it might have been regarding DHCPv4?

- Ralph

At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote:
>I mean't to bring up the version number before.  We were asked for this some
>time ago and a suggestion from several.  I can't recall arguments against it
>and it may have fell through the cracks?
>
>/jim
>
> > -----Original Message-----
> > From: ext ebenezer schubert [mailto:ebi@cup.hp.com]
> > Sent: Friday,March 16,2001 3:12 PM
> > To: DHCPv6 discussion list
> > Subject: Re: why seperate Ia is needed for sending new Requests?
> >
> >
> > Hi,
> >
> >     I would agree with what Jim is saying. The market
> >     is ready for DHCPv6 and we need some conclusion
> >     on this fast.
> >
> >    At the same time there should be some scope for
> >    whatever the future versions to interoperate with
> >    the older ones. I would like to make 2 suggestions
> >    in this regard
> >
> >     1. To have an unimplemented error message.
> >     2. To have a version field in the header.
> >
> >    So that even if the IESG takes a long time to make
> >    a standard. We can proceed with the existing drafts,
> >    if the standard is different from the draft, we should
> >    be able to handle them easily.
> >
> >
> > -ebi
> > Hewlett-Packard
> > 408-447-7652
> >
> > ----- Original Message -----
> > From: <Jim.Bound@nokia.com>
> > To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
> > Sent: Friday, March 16, 2001 7:50 AM
> > Subject: RE: why seperate Ia is needed for sending new Requests?
> >
> >
> > > hi ralph,
> > >
> > > I agree with you in spirit but the flesh is weak.  we have
> > chased the
> > client
> > > telling servers "I want x addresses" for a long time.  I
> > suggest as I
> > do for
> > > reconf-init multicast we not permit in our effort to get to PS.  We
> > will not
> > > reach consensus and the market is ready for dhcp using ipv6. I also
> > believe
> > > reality is that most clients will get a default number of addresses
> > from the
> > > server.  clients that send another IA will get x addresses as they
> > will be
> > > special anyway.  So though in "theory" it seems messy, in practice I
> > think
> > > it will work fine.
> > >
> > > for temporary addresses I think the client setting a bit in
> > IA Status
> > will
> > > tell the server I need to "note" temporary addresses.  When the
> > server
> > > responds it will send x addresses to the client.  Before
> > each address
> > a bit
> > > will be set in the addr status field that this address is "noted" as
> > > temporary.  I really don't think temporary addresses is a complex
> > thing and
> > > I think we need to be careful we don't over complicate this part of
> > what we
> > > need to do.  at the server for the T1,T2,Preferred, and Valid
> > lifetimes the
> > > server can apply the recommendations of rfc 3041 to the
> > times it uses
> > to
> > > provide the client leases.  Pretty simplex stuff I think.  then we
> > just need
> > > to make a decision on whether we let server renew temporary
> > addresses.  in
> > > the design call I think I heard it was ok to extend the valid
> > lifetime but
> > > not the preferred lifetime.  I think we should be able to wrap this
> > up at
> > > minneapolis.
> > >
> > > what would be really useful for the wed dhcpv6 venue is if ted could
> > provide
> > > the format and datum picture of the IA + client-id parts for the IA
> > option
> > > and the text for forming it so we can discuss.  That is necessary to
> > go to
> > > last call.  I think this is the most important and critical item we
> > work on
> > > next week.
> > >
> > > thanks
> > >
> > > /jim
> > >
> > > > -----Original Message-----
> > > > From: ext Ralph Droms [mailto:rdroms@cisco.com]
> > > > Sent: Thursday,March 15,2001 7:57 PM
> > > > To: DHCPv6 discussion list
> > > > Cc: DHCPv6 discussion list
> > > > Subject: RE: why seperate Ia is needed for sending new Requests?
> > > >
> > > >
> > > > If I remember correctly, we've considered the issue of
> > > > virtual web servers
> > > > in the past.  Based on the capabilities of the current
> > > > version of HTTP for
> > > > identifying virtual web servers behind a single IP address,
> > > > we've discarded
> > > > virtual web servers as a motivation for on-demand address
> > assignment.
> > > >
> > > > That's not to say there aren't other motivations for
> > > > on-demand address
> > > > assignment.  Perhaps temporary addresses are a good
> > > > motivating example.  If
> > > > we're going to add complexity to the protocol to support
> > > > on-demand address
> > > > assignment, we need to make sure we understand the specific
> > > > motivations and
> > > > requirements.
> > > >
> > > > - Ralph
> > > >
> > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote:
> > > > >It is entirely possible for a client to ask for more
> > > > "normal" addresses.
> > > > >The reason being in IPv4, addresses were a bottle neck and
> > > > in IPv6 it wont
> > > > >be. A server that does web hosting may need thousands of IP
> > > > addresses and
> > > > >it may not be possible to know the requirement ahead of time
> > > > in all cases.
> > > > >It will contact the DHCP Server to request more IP addresses
> > > > in this case
> > > > >or use stateless config to generate the IPs it needs. A
> > > > server hosting
> > > > >different services may want to use different "normal"
> > > > addresses for each
> > > > >service.
> > > >
> > > >
> > > >
> > >
> >

------_=_NextPart_001_01C0AE9C.F3C46700-- From owner-dhcp-v6@bucknell.edu Fri Mar 16 23:54:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20451; Fri, 16 Mar 2001 23:54:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2H4sLL09638; Fri, 16 Mar 2001 23:54:21 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2H4sCL28657 for ; Fri, 16 Mar 2001 23:54:12 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2H4sEg00719 for ; Fri, 16 Mar 2001 22:54:14 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 16 Mar 2001 22:54:12 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 16 Mar 2001 22:54:11 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Fri, 16 Mar 2001 22:54:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 this is a good taxonomy for discussion point. thanks. I also don't think we should use a port number. I want to know from the protocol the version has changed not by looking at the port number nor do I want to run different versions of dhcpv6. /jim > -----Original Message----- > From: ext Ebenezer Schubert [mailto:ebi@cup.hp.com] > Sent: Friday,March 16,2001 6:10 PM > To: DHCPv6 discussion list > Subject: Re: why seperate Ia is needed for sending new Requests? > > > Hi, > > As long as there is an agreement that any new > functionality starting > from draft revision xxxx, there would be no > changes to the msg > structure or the interpretation of existing message > types and any > new feature would be through the introduction of a new > message type. > Then it is ok. > > But right now, there seems to be a lot of changes. > So having a > version no. field, can help to start the > development activity > parallel to the work in the IETF. > > This is the reason why revising the protocol port > no. would not > make any sense, because we may not be able to > change port nos, > between different versions of the draft. Also, we > cannot gurantee, > that the interpretation of a particular message type > will not change > until this becomes an RFC. > > -ebi > > > > Ralph: > > > > Wish I could remember the details as well. > > > > I think one argument might be that why not just change the > UDP port number if you revise the protocol? > > > > Another is that by using a version number, you might not > gain that much because at least part of the message format > must stay the same in order to be able to recognize that this > is a new version of the protocol. > > > > And, a third possiblity is that since the message type is > the first byte, why not just use new message types? > > > > And, forth, future revisions of the protocol could be > handled by sending a special option on the Advertise or > Solicit to indicate that the server is capable of the > extended functionality. Though in this case, the basic > message format has to be retained. > > > > BTW: Regarding the error message issue, how about we have a > message type which can be sent by a agent (server or relay) > to respond to a client to return some error. That way, if the > client sends an unknown message type, the server (or relay) > can respond. This message type MUST be unicast by the relay > or server. That message type might be formatted as follows: > > > > 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 | error-number | error-text > | > > . > . > > . > . > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Probably the only error number that is needed today is > "unknown/unimplemented message type"? > > > > - Bernie > > > > -----Original Message----- > > From: Ralph Droms [mailto:droms@bucknell.edu] > > Sent: Friday, March 16, 2001 5:11 PM > > To: DHCPv6 discussion list > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > It's Friday afternoon, my wife's been visiting her mother > in Wisconsin all > > week and I'm rushing around getting ready to go to > Minneapolis - so I'm > > having trouble remembering the details about previous > discussions about a > > version number in the DHCP message header. > > > > But it strikes me that we came to the conclusion that a > version number > > turns out to be not all that useful. Does anyone else > remember having this > > discussion previously - it might have been regarding DHCPv4? > > > > - Ralph > > > > At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: > > >I mean't to bring up the version number before. We were > asked for this some > > >time ago and a suggestion from several. I can't recall > arguments against it > > >and it may have fell through the cracks? > > > > > >/jim > > > > > > > -----Original Message----- > > > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com] > > > > Sent: Friday,March 16,2001 3:12 PM > > > > To: DHCPv6 discussion list > > > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > Hi, > > > > > > > > I would agree with what Jim is saying. The market > > > > is ready for DHCPv6 and we need some conclusion > > > > on this fast. > > > > > > > > At the same time there should be some scope for > > > > whatever the future versions to interoperate with > > > > the older ones. I would like to make 2 suggestions > > > > in this regard > > > > > > > > 1. To have an unimplemented error message. > > > > 2. To have a version field in the header. > > > > > > > > So that even if the IESG takes a long time to make > > > > a standard. We can proceed with the existing drafts, > > > > if the standard is different from the draft, we should > > > > be able to handle them easily. > > > > > > > > > > > > -ebi > > > > Hewlett-Packard > > > > 408-447-7652 > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: DHCPv6 discussion list > > > > Sent: Friday, March 16, 2001 7:50 AM > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > > hi ralph, > > > > > > > > > > I agree with you in spirit but the flesh is weak. we have > > > > chased the > > > > client > > > > > telling servers "I want x addresses" for a long time. I > > > > suggest as I > > > > do for > > > > > reconf-init multicast we not permit in our effort to > get to PS. We > > > > will not > > > > > reach consensus and the market is ready for dhcp > using ipv6. I also > > > > believe > > > > > reality is that most clients will get a default > number of addresses > > > > from the > > > > > server. clients that send another IA will get x > addresses as they > > > > will be > > > > > special anyway. So though in "theory" it seems > messy, in practice I > > > > think > > > > > it will work fine. > > > > > > > > > > for temporary addresses I think the client setting a bit in > > > > IA Status > > > > will > > > > > tell the server I need to "note" temporary addresses. > When the > > > > server > > > > > responds it will send x addresses to the client. Before > > > > each address > > > > a bit > > > > > will be set in the addr status field that this > address is "noted" as > > > > > temporary. I really don't think temporary addresses > is a complex > > > > thing and > > > > > I think we need to be careful we don't over > complicate this part of > > > > what we > > > > > need to do. at the server for the T1,T2,Preferred, and Valid > > > > lifetimes the > > > > > server can apply the recommendations of rfc 3041 to the > > > > times it uses > > > > to > > > > > provide the client leases. Pretty simplex stuff I > think. then we > > > > just need > > > > > to make a decision on whether we let server renew temporary > > > > addresses. in > > > > > the design call I think I heard it was ok to extend the valid > > > > lifetime but > > > > > not the preferred lifetime. I think we should be > able to wrap this > > > > up at > > > > > minneapolis. > > > > > > > > > > what would be really useful for the wed dhcpv6 venue > is if ted could > > > > provide > > > > > the format and datum picture of the IA + client-id > parts for the IA > > > > option > > > > > and the text for forming it so we can discuss. That > is necessary to > > > > go to > > > > > last call. I think this is the most important and > critical item we > > > > work on > > > > > next week. > > > > > > > > > > thanks > > > > > > > > > > /jim > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > > > To: DHCPv6 discussion list > > > > > > Cc: DHCPv6 discussion list > > > > > > Subject: RE: why seperate Ia is needed for sending > new Requests? > > > > > > > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > > > virtual web servers > > > > > > in the past. Based on the capabilities of the current > > > > > > version of HTTP for > > > > > > identifying virtual web servers behind a single IP address, > > > > > > we've discarded > > > > > > virtual web servers as a motivation for on-demand address > > > > assignment. > > > > > > > > > > > > That's not to say there aren't other motivations for > > > > > > on-demand address > > > > > > assignment. Perhaps temporary addresses are a good > > > > > > motivating example. If > > > > > > we're going to add complexity to the protocol to support > > > > > > on-demand address > > > > > > assignment, we need to make sure we understand the specific > > > > > > motivations and > > > > > > requirements. > > > > > > > > > > > > - Ralph > > > > > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > > > >It is entirely possible for a client to ask for more > > > > > > "normal" addresses. > > > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > > > in IPv6 it wont > > > > > > >be. A server that does web hosting may need thousands of IP > > > > > > addresses and > > > > > > >it may not be possible to know the requirement > ahead of time > > > > > > in all cases. > > > > > > >It will contact the DHCP Server to request more IP > addresses > > > > > > in this case > > > > > > >or use stateless config to generate the IPs it needs. A > > > > > > server hosting > > > > > > >different services may want to use different "normal" > > > > > > addresses for each > > > > > > >service. > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-dhcp-v6@bucknell.edu Mon Mar 19 00:45:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19432; Mon, 19 Mar 2001 00:45:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2J5gPe24496; Mon, 19 Mar 2001 00:42:25 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2J5gLe25267 for ; Mon, 19 Mar 2001 00:42:21 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id VAA13130; Sun, 18 Mar 2001 21:42:08 -0800 (PST) Received: from rdroms-w2k.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2J5g2x13838; Sun, 18 Mar 2001 21:42:02 -0800 (PST) Message-Id: <4.3.2.7.2.20010318215801.00b986f0@134.82.9.1> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Mar 2001 00:39:01 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Question about REBIND message Cc: DHCPv6 discussion list In-Reply-To: <3AAFA544.7CF06988@crm.mot.com> References: 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 06:07 PM 3/14/2001 +0100, Jerome Labussiere wrote: >Jim.Bound@nokia.com wrote: > > > > > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > > > Sent: Wednesday,March 14,2001 9:49 AM > > > To: DHCPv6 discussion list > > > Subject: Question about REBIND message > > > > > > In the -18 rev, it is said that the client send the REBIND > > > message at T2 > > > (section 16.2) to 'any available server' in order to extend the > > > lifetimes of an IA, if the primary server has not responded at T1. I > > > guess 'any available server' means any server which can receive the > > > message (because it is onlink or via a relay). However, according to > > > section 13.4.4 the server can successfully extend the > > > lifetimes only if > > > it has a binding for this client. > > > > thats correct. the idea is if another server thru some other means can do > > this we don't want to prohibit the function for rebind. I disagree - I think there is an error in the -18 rev of the DHCPv6 spec. A server should silently discard any Rebind messages to which it cannot respond. DHCPv4 leaves the decision about whether to respond to a DHCPREQUEST from a client in REBINDING state to loca administrative control (section 4.3.2 of RFC2131): > A DHCP server MAY extend a client's lease only if it has local > administrative authority to do so. Implicitly, a DHCPv4 server may create a new binding and extend the lease of a previously unknown client if the server is authorized to do so. I suggest that the text in the DHCPv6 spec should be changed to read: If the server cannot find a client entry for this IA, the server MAY create a new binding for the IA and send a Reply message to the client with the lease on the IA. If the server does not create a new binding it MUST silently discard the Rebind message. This text may need to be extended to specify that the server may *only* change the lease on the IA and *may not* make any other changes to the addresses assigned to the IA. - Ralph From owner-dhcp-v6@bucknell.edu Mon Mar 19 00:46:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19474; Mon, 19 Mar 2001 00:46:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2J5hfe25684; Mon, 19 Mar 2001 00:43:41 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2J5gLe25497 for ; Mon, 19 Mar 2001 00:42:21 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id VAA12601; Sun, 18 Mar 2001 21:40:49 -0800 (PST) Received: from rdroms-w2k.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2J5fxx13817; Sun, 18 Mar 2001 21:41:59 -0800 (PST) Message-Id: <4.3.2.7.2.20010318203917.00b7c9d8@134.82.9.1> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Mar 2001 00:38:55 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Question about REBIND message Cc: DHCPv6 discussion list In-Reply-To: <3AAFA544.7CF06988@crm.mot.com> References: 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 06:07 PM 3/14/2001 +0100, Jerome Labussiere wrote: >Still one dark point: About 'reacting immediately', I've the feeling >that it works with one DHCP server in the domain. But with two ? For >instance, if the client has a binding with server A. For a good reason, >it has to send a CONFIRM message. Server A and server B receive the >CONFIRM and answer. A returns a REPLY/status 0 and B returns a >REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by >the client and A's REPLY is received one or two ms after. If the client >reacts immediately, according to section 13.3.5, it has to assume that >the IA is lost and that it needs to notify the application layer and to >send a Request to reestablish an IA with B. The first REPLY is not >necessarily the best. I can't find anything in the spec about this. Jerome, You've identified a potential error in the DHCPv6 spec. The following text in 13.4.2 of the -18: > If the server cannot find a client entry for this IA the server > SHOULD return an empty IA with status set to NoBinding. is, IMHO, wrong. A server should ignore a CONFIRM message for which it has no information. IN DHCPv4, servers with no information about a binding do not respond to a request from a client to confirm the correctness of its address (DHCPREQUEST in INIT_REBOOT state). Here is the related text from DHCPv4, RC2131, section 3.2: > 2. Servers with knowledge of the client's configuration parameters > respond with a DHCPACK message to the client. Servers SHOULD NOT > check that the client's network address is already in use; the > client may respond to ICMP Echo Request messages at this point. > If the client's request is invalid (e.g., the client has moved > to a new subnet), servers SHOULD respond with a DHCPNAK message to > the client. Servers SHOULD NOT respond if their information is not > guaranteed to be accurate. For example, a server that identifies a > request for an expired binding that is owned by another server SHOULD > NOT respond with a DHCPNAK unless the servers are using an explicit > mechanism to maintain coherency among the servers. The text in 13.4.2 of the -18 rev of the DHCPv6 spec should read: > If the server cannot find a client entry for this IA the server > MUST silently discard the Confirm message. Ralph From owner-dhcp-v6@bucknell.edu Mon Mar 19 01:31:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22202; Mon, 19 Mar 2001 01:31:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2J6Sae32295; Mon, 19 Mar 2001 01:28:36 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2J6SKe32184 for ; Mon, 19 Mar 2001 01:28:20 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2J6Rtm06930 for ; Mon, 19 Mar 2001 00:27:55 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2J6Rtj27040 for ; Mon, 19 Mar 2001 00:27:55 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Mar 19 00:27:54 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Mar 2001 00:29:43 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB873@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Mon, 19 Mar 2001 00:29:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B03D.FAA07FD0" 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 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_001_01C0B03D.FAA07FD0 Content-Type: text/plain; charset="iso-8859-1" Why do we need a version number during DEVELOPMENT of the protocol. It is pretty usual for I-Ds to change over time and that's just the price you pay for implementing early. I don't see a need to introduce a version number during the development phase. We really need to be able to maintain the flexibility to change things (though let's hope we're only doing very minor tweaks now if any!). I thought the original version number question was raised regarding the longer term issue - post RFC status how to we evolve it from there should we want to. I guess not. - Bernie -----Original Message----- From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com] Sent: Friday, March 16, 2001 11:54 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? this is a good taxonomy for discussion point. thanks. I also don't think we should use a port number. I want to know from the protocol the version has changed not by looking at the port number nor do I want to run different versions of dhcpv6. /jim > -----Original Message----- > From: ext Ebenezer Schubert [mailto:ebi@cup.hp.com] > Sent: Friday,March 16,2001 6:10 PM > To: DHCPv6 discussion list > Subject: Re: why seperate Ia is needed for sending new Requests? > > > Hi, > > As long as there is an agreement that any new > functionality starting > from draft revision xxxx, there would be no > changes to the msg > structure or the interpretation of existing message > types and any > new feature would be through the introduction of a new > message type. > Then it is ok. > > But right now, there seems to be a lot of changes. > So having a > version no. field, can help to start the > development activity > parallel to the work in the IETF. > > This is the reason why revising the protocol port > no. would not > make any sense, because we may not be able to > change port nos, > between different versions of the draft. Also, we > cannot gurantee, > that the interpretation of a particular message type > will not change > until this becomes an RFC. > > -ebi > > > > Ralph: > > > > Wish I could remember the details as well. > > > > I think one argument might be that why not just change the > UDP port number if you revise the protocol? > > > > Another is that by using a version number, you might not > gain that much because at least part of the message format > must stay the same in order to be able to recognize that this > is a new version of the protocol. > > > > And, a third possiblity is that since the message type is > the first byte, why not just use new message types? > > > > And, forth, future revisions of the protocol could be > handled by sending a special option on the Advertise or > Solicit to indicate that the server is capable of the > extended functionality. Though in this case, the basic > message format has to be retained. > > > > BTW: Regarding the error message issue, how about we have a > message type which can be sent by a agent (server or relay) > to respond to a client to return some error. That way, if the > client sends an unknown message type, the server (or relay) > can respond. This message type MUST be unicast by the relay > or server. That message type might be formatted as follows: > > > > 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 | error-number | error-text > | > > . > . > > . > . > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Probably the only error number that is needed today is > "unknown/unimplemented message type"? > > > > - Bernie > > > > -----Original Message----- > > From: Ralph Droms [mailto:droms@bucknell.edu] > > Sent: Friday, March 16, 2001 5:11 PM > > To: DHCPv6 discussion list > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > It's Friday afternoon, my wife's been visiting her mother > in Wisconsin all > > week and I'm rushing around getting ready to go to > Minneapolis - so I'm > > having trouble remembering the details about previous > discussions about a > > version number in the DHCP message header. > > > > But it strikes me that we came to the conclusion that a > version number > > turns out to be not all that useful. Does anyone else > remember having this > > discussion previously - it might have been regarding DHCPv4? > > > > - Ralph > > > > At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: > > >I mean't to bring up the version number before. We were > asked for this some > > >time ago and a suggestion from several. I can't recall > arguments against it > > >and it may have fell through the cracks? > > > > > >/jim > > > > > > > -----Original Message----- > > > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com] > > > > Sent: Friday,March 16,2001 3:12 PM > > > > To: DHCPv6 discussion list > > > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > Hi, > > > > > > > > I would agree with what Jim is saying. The market > > > > is ready for DHCPv6 and we need some conclusion > > > > on this fast. > > > > > > > > At the same time there should be some scope for > > > > whatever the future versions to interoperate with > > > > the older ones. I would like to make 2 suggestions > > > > in this regard > > > > > > > > 1. To have an unimplemented error message. > > > > 2. To have a version field in the header. > > > > > > > > So that even if the IESG takes a long time to make > > > > a standard. We can proceed with the existing drafts, > > > > if the standard is different from the draft, we should > > > > be able to handle them easily. > > > > > > > > > > > > -ebi > > > > Hewlett-Packard > > > > 408-447-7652 > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: DHCPv6 discussion list > > > > Sent: Friday, March 16, 2001 7:50 AM > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > > hi ralph, > > > > > > > > > > I agree with you in spirit but the flesh is weak. we have > > > > chased the > > > > client > > > > > telling servers "I want x addresses" for a long time. I > > > > suggest as I > > > > do for > > > > > reconf-init multicast we not permit in our effort to > get to PS. We > > > > will not > > > > > reach consensus and the market is ready for dhcp > using ipv6. I also > > > > believe > > > > > reality is that most clients will get a default > number of addresses > > > > from the > > > > > server. clients that send another IA will get x > addresses as they > > > > will be > > > > > special anyway. So though in "theory" it seems > messy, in practice I > > > > think > > > > > it will work fine. > > > > > > > > > > for temporary addresses I think the client setting a bit in > > > > IA Status > > > > will > > > > > tell the server I need to "note" temporary addresses. > When the > > > > server > > > > > responds it will send x addresses to the client. Before > > > > each address > > > > a bit > > > > > will be set in the addr status field that this > address is "noted" as > > > > > temporary. I really don't think temporary addresses > is a complex > > > > thing and > > > > > I think we need to be careful we don't over > complicate this part of > > > > what we > > > > > need to do. at the server for the T1,T2,Preferred, and Valid > > > > lifetimes the > > > > > server can apply the recommendations of rfc 3041 to the > > > > times it uses > > > > to > > > > > provide the client leases. Pretty simplex stuff I > think. then we > > > > just need > > > > > to make a decision on whether we let server renew temporary > > > > addresses. in > > > > > the design call I think I heard it was ok to extend the valid > > > > lifetime but > > > > > not the preferred lifetime. I think we should be > able to wrap this > > > > up at > > > > > minneapolis. > > > > > > > > > > what would be really useful for the wed dhcpv6 venue > is if ted could > > > > provide > > > > > the format and datum picture of the IA + client-id > parts for the IA > > > > option > > > > > and the text for forming it so we can discuss. That > is necessary to > > > > go to > > > > > last call. I think this is the most important and > critical item we > > > > work on > > > > > next week. > > > > > > > > > > thanks > > > > > > > > > > /jim > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Ralph Droms [mailto:rdroms@cisco.com] > > > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > > > To: DHCPv6 discussion list > > > > > > Cc: DHCPv6 discussion list > > > > > > Subject: RE: why seperate Ia is needed for sending > new Requests? > > > > > > > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > > > virtual web servers > > > > > > in the past. Based on the capabilities of the current > > > > > > version of HTTP for > > > > > > identifying virtual web servers behind a single IP address, > > > > > > we've discarded > > > > > > virtual web servers as a motivation for on-demand address > > > > assignment. > > > > > > > > > > > > That's not to say there aren't other motivations for > > > > > > on-demand address > > > > > > assignment. Perhaps temporary addresses are a good > > > > > > motivating example. If > > > > > > we're going to add complexity to the protocol to support > > > > > > on-demand address > > > > > > assignment, we need to make sure we understand the specific > > > > > > motivations and > > > > > > requirements. > > > > > > > > > > > > - Ralph > > > > > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > > > >It is entirely possible for a client to ask for more > > > > > > "normal" addresses. > > > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > > > in IPv6 it wont > > > > > > >be. A server that does web hosting may need thousands of IP > > > > > > addresses and > > > > > > >it may not be possible to know the requirement > ahead of time > > > > > > in all cases. > > > > > > >It will contact the DHCP Server to request more IP > addresses > > > > > > in this case > > > > > > >or use stateless config to generate the IPs it needs. A > > > > > > server hosting > > > > > > >different services may want to use different "normal" > > > > > > addresses for each > > > > > > >service. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0B03D.FAA07FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: why seperate Ia is needed for sending new Requests?

Why do we need a version number during DEVELOPMENT of = the protocol. It
is pretty usual for I-Ds to change over time and = that's just the price
you pay for implementing early. I don't see a need = to introduce a
version number during the development phase. We = really need to be able
to maintain the flexibility to change things (though = let's hope we're
only doing very minor tweaks now if any!).

I thought the original version number question was = raised regarding the
longer term issue - post RFC status how to we evolve = it from there
should we want to. I guess not.

- Bernie

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 11:54 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending = new Requests?


this is a good taxonomy for discussion point.  = thanks.
I also don't think we should use a port number. I = want to know from the
protocol the version has changed not by looking at = the port number nor do I
want to run different versions of dhcpv6.

/jim

> -----Original Message-----
> From: ext Ebenezer Schubert [mailto:ebi@cup.hp.com]
> Sent: Friday,March 16,2001 6:10 PM
> To: DHCPv6 discussion list
> Subject: Re: why seperate Ia is needed for = sending new Requests?
>
>
> Hi,
>
>       As long as there = is an agreement that any new
> functionality starting
>       from  = draft  revision  xxxx,  there  would be no
> changes  to the msg
>       structure or = the  interpretation  of existing  message
> types and any
>       new feature = would be through the introduction of a new
> message type.
>       Then it is = ok.
>
>       But right  = now,  there  seems to be a lot of  changes.  =
> So  having a
>       version  = no.  field,  can help to  start  the 
> development  activity
>       parallel to the = work in the IETF.
>
>       This is the = reason why  revising  the  protocol  port
> no.  would not
>       make any  = sense,  because  we may not be able to 
> change  port  nos,
>       between = different  versions of the draft.  Also, we
> cannot gurantee,
>       that the = interpretation of a particular message type
> will not change
>       until this = becomes an RFC.
>
> -ebi
>
>
> > Ralph:
> >
> > Wish I could remember the details as = well.
> >
> > I think one argument might be that why not = just change the
> UDP port number if you revise the = protocol?
> >
> > Another is that by using a version number, = you might not
> gain that much because at least part of the = message format
> must stay the same in order to be able to = recognize that this
> is a new version of the protocol.
> >
> > And, a third possiblity is that since the = message type is
> the first byte, why not just use new message = types?
> >
> > And, forth, future revisions of the = protocol could be
> handled by sending a special option on the = Advertise or
> Solicit to indicate that the server is capable = of the
> extended functionality. Though in this case, = the basic
> message format has to be retained.
> >
> > BTW: Regarding the error message issue, = how about we have a
> message type which can be sent by a agent = (server or relay)
> to respond to a client to return some error. = That way, if the
> client sends an unknown message type, the = server (or relay)
> can respond. This message type MUST be unicast = by the relay
> or server. That message type might be formatted = as follows:
> >
> >       = 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   |  error-number = |      = error-text     
>          = |
> >      = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;     
>          = .
> >      = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;     
>          = .
> >      = |            = ;            = ;            = ;            = ;     
>          = |
> >     
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >
> > Probably the only error number that is = needed today is
> "unknown/unimplemented message = type"?
> >
> > - Bernie
> >
> > -----Original Message-----
> > From: Ralph Droms [mailto:droms@bucknell.edu]=
> > Sent: Friday, March 16, 2001 5:11 = PM
> > To: DHCPv6 discussion list
> > Subject: RE: why seperate Ia is needed for = sending new Requests?
> >
> >
> > It's Friday afternoon, my wife's been = visiting her mother
> in Wisconsin all
> > week and I'm rushing around getting ready = to go to
> Minneapolis - so I'm
> > having trouble remembering the details = about previous
> discussions about a
> > version number in the DHCP message = header.
> >
> > But it strikes me that we came to the = conclusion that a
> version number
> > turns out to be not all that useful.  = Does anyone else
> remember having this
> > discussion previously - it might have been = regarding DHCPv4?
> >
> > - Ralph
> >
> > At 03:25 PM 3/16/2001 -0600, = Jim.Bound@nokia.com wrote:
> > >I mean't to bring up the version = number before.  We were
> asked for this some
> > >time ago and a suggestion from = several.  I can't recall
> arguments against it
> > >and it may have fell through the = cracks?
> > >
> > >/jim
> > >
> > > > -----Original = Message-----
> > > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com]
> > > > Sent: Friday,March 16,2001 3:12 = PM
> > > > To: DHCPv6 discussion = list
> > > > Subject: Re: why seperate Ia is = needed for sending new Requests?
> > > >
> > > >
> > > > Hi,
> > > >
> > > >     I would = agree with what Jim is saying. The market
> > > >     is ready = for DHCPv6 and we need some conclusion
> > > >     on this = fast.
> > > >
> > > >    At the same = time there should be some scope for
> > > >    whatever the = future versions to interoperate with
> > > >    the older = ones. I would like to make 2 suggestions
> > > >    in this = regard
> > > >
> > > >     1. To = have an unimplemented error message.
> > > >     2. To = have a version field in the header.
> > > >
> > > >    So that even = if the IESG takes a long time to make
> > > >    a standard. We = can proceed with the existing drafts,
> > > >    if the = standard is different from the draft, we should
> > > >    be able to = handle them easily.
> > > >
> > > >
> > > > -ebi
> > > > Hewlett-Packard
> > > > 408-447-7652
> > > >
> > > > ----- Original Message = -----
> > > > From: = <Jim.Bound@nokia.com>
> > > > To: DHCPv6 discussion list = <dhcp-v6@bucknell.edu>
> > > > Sent: Friday, March 16, 2001 = 7:50 AM
> > > > Subject: RE: why seperate Ia is = needed for sending new Requests?
> > > >
> > > >
> > > > > hi ralph,
> > > > >
> > > > > I agree with you in spirit = but the flesh is weak.  we have
> > > > chased the
> > > > client
> > > > > telling servers "I = want x addresses" for a long time.  I
> > > > suggest as I
> > > > do for
> > > > > reconf-init multicast we = not permit in our effort to
> get to PS.  We
> > > > will not
> > > > > reach consensus and the = market is ready for dhcp
> using ipv6. I also
> > > > believe
> > > > > reality is that most = clients will get a default
> number of addresses
> > > > from the
> > > > > server.  clients that = send another IA will get x
> addresses as they
> > > > will be
> > > > > special anyway.  So = though in "theory" it seems
> messy, in practice I
> > > > think
> > > > > it will work fine.
> > > > >
> > > > > for temporary addresses I = think the client setting a bit in
> > > > IA Status
> > > > will
> > > > > tell the server I need to = "note" temporary addresses.
>  When the
> > > > server
> > > > > responds it will send x = addresses to the client.  Before
> > > > each address
> > > > a bit
> > > > > will be set in the addr = status field that this
> address is "noted" as
> > > > > temporary.  I really = don't think temporary addresses
> is a complex
> > > > thing and
> > > > > I think we need to be = careful we don't over
> complicate this part of
> > > > what we
> > > > > need to do.  at the = server for the T1,T2,Preferred, and Valid
> > > > lifetimes the
> > > > > server can apply the = recommendations of rfc 3041 to the
> > > > times it uses
> > > > to
> > > > > provide the client = leases.  Pretty simplex stuff I
> think.  then we
> > > > just need
> > > > > to make a decision on = whether we let server renew temporary
> > > > addresses.  in
> > > > > the design call I think I = heard it was ok to extend the valid
> > > > lifetime but
> > > > > not the preferred = lifetime.  I think we should be
> able to wrap this
> > > > up at
> > > > > minneapolis.
> > > > >
> > > > > what would be really useful = for the wed dhcpv6 venue
> is if ted could
> > > > provide
> > > > > the format and datum = picture of the IA + client-id
> parts for the IA
> > > > option
> > > > > and the text for forming it = so we can discuss.  That
> is necessary to
> > > > go to
> > > > > last call.  I think = this is the most important and
> critical item we
> > > > work on
> > > > > next week.
> > > > >
> > > > > thanks
> > > > >
> > > > > /jim
> > > > >
> > > > > > -----Original = Message-----
> > > > > > From: ext Ralph Droms = [mailto:rdroms@cisco.com]
> > > > > > Sent: Thursday,March = 15,2001 7:57 PM
> > > > > > To: DHCPv6 discussion = list
> > > > > > Cc: DHCPv6 discussion = list
> > > > > > Subject: RE: why = seperate Ia is needed for sending
> new Requests?
> > > > > >
> > > > > >
> > > > > > If I remember = correctly, we've considered the issue of
> > > > > > virtual web = servers
> > > > > > in the past.  = Based on the capabilities of the current
> > > > > > version of HTTP = for
> > > > > > identifying virtual = web servers behind a single IP address,
> > > > > > we've discarded
> > > > > > virtual web servers as = a motivation for on-demand address
> > > > assignment.
> > > > > >
> > > > > > That's not to say = there aren't other motivations for
> > > > > > on-demand = address
> > > > > > assignment.  = Perhaps temporary addresses are a good
> > > > > > motivating = example.  If
> > > > > > we're going to add = complexity to the protocol to support
> > > > > > on-demand = address
> > > > > > assignment, we need to = make sure we understand the specific
> > > > > > motivations and
> > > > > > requirements.
> > > > > >
> > > > > > - Ralph
> > > > > >
> > > > > > At 07:31 AM 3/15/2001 = -0800, Thirumalesh Bhat wrote:
> > > > > > >It is entirely = possible for a client to ask for more
> > > > > > "normal" = addresses.
> > > > > > >The reason being = in IPv4, addresses were a bottle neck and
> > > > > > in IPv6 it wont
> > > > > > >be. A server that = does web hosting may need thousands of IP
> > > > > > addresses and
> > > > > > >it may not be = possible to know the requirement
> ahead of time
> > > > > > in all cases.
> > > > > > >It will contact = the DHCP Server to request more IP
> addresses
> > > > > > in this case
> > > > > > >or use stateless = config to generate the IPs it needs. A
> > > > > > server hosting
> > > > > > >different services = may want to use different "normal"
> > > > > > addresses for = each
> > > > > > >service.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
>

------_=_NextPart_001_01C0B03D.FAA07FD0-- From owner-dhcp-v6@bucknell.edu Mon Mar 19 01:43:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23695; Mon, 19 Mar 2001 01:43:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2J6gGe01242; Mon, 19 Mar 2001 01:42:16 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2J6g1e32077 for ; Mon, 19 Mar 2001 01:42:01 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2J6g0m08598 for ; Mon, 19 Mar 2001 00:42:00 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2J6g0j27611 for ; Mon, 19 Mar 2001 00:42:00 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Mar 19 00:41:59 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Mar 2001 00:43:48 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB874@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Question about REBIND message Date: Mon, 19 Mar 2001 00:43:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B03F.F27DC1D0" 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 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_001_01C0B03F.F27DC1D0 Content-Type: text/plain; charset="iso-8859-1" Ralph: Can a server REJECT the REBIND? Suppose a server finds that one or more of the addresses is in use by a different binding? Can the server add more addresses to the REBIND? It could on a RENEW, so why can't this happen on a REBIND? The difference between the REBIND and the RENEW is simply that for the REBIND some other server (if authoritative for the network) can respond in the same way that the original server could have on a RENEW. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, March 19, 2001 12:39 AM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: Question about REBIND message At 06:07 PM 3/14/2001 +0100, Jerome Labussiere wrote: >Jim.Bound@nokia.com wrote: > > > > > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@crm.mot.com] > > > Sent: Wednesday,March 14,2001 9:49 AM > > > To: DHCPv6 discussion list > > > Subject: Question about REBIND message > > > > > > In the -18 rev, it is said that the client send the REBIND > > > message at T2 > > > (section 16.2) to 'any available server' in order to extend the > > > lifetimes of an IA, if the primary server has not responded at T1. I > > > guess 'any available server' means any server which can receive the > > > message (because it is onlink or via a relay). However, according to > > > section 13.4.4 the server can successfully extend the > > > lifetimes only if > > > it has a binding for this client. > > > > thats correct. the idea is if another server thru some other means can do > > this we don't want to prohibit the function for rebind. I disagree - I think there is an error in the -18 rev of the DHCPv6 spec. A server should silently discard any Rebind messages to which it cannot respond. DHCPv4 leaves the decision about whether to respond to a DHCPREQUEST from a client in REBINDING state to loca administrative control (section 4.3.2 of RFC2131): > A DHCP server MAY extend a client's lease only if it has local > administrative authority to do so. Implicitly, a DHCPv4 server may create a new binding and extend the lease of a previously unknown client if the server is authorized to do so. I suggest that the text in the DHCPv6 spec should be changed to read: If the server cannot find a client entry for this IA, the server MAY create a new binding for the IA and send a Reply message to the client with the lease on the IA. If the server does not create a new binding it MUST silently discard the Rebind message. This text may need to be extended to specify that the server may *only* change the lease on the IA and *may not* make any other changes to the addresses assigned to the IA. - Ralph ------_=_NextPart_001_01C0B03F.F27DC1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question about REBIND message

Ralph:

Can a server REJECT the REBIND? Suppose a server = finds that one or more
of the addresses is in use by a different = binding?

Can the server add more addresses to the REBIND? It = could on a RENEW, so
why can't this happen on a REBIND?

The difference between the REBIND and the RENEW is = simply that for the
REBIND some other server (if authoritative for the = network) can respond
in the same way that the original server could have = on a RENEW.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, March 19, 2001 12:39 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: Question about REBIND message


At 06:07 PM 3/14/2001 +0100, Jerome Labussiere = wrote:
>Jim.Bound@nokia.com wrote:
> >
> > > From: ext Jerome Labussiere [mailto:Jerome.Labussiere@c= rm.mot.com]
> > > Sent: Wednesday,March 14,2001 9:49 = AM
> > > To: DHCPv6 discussion list
> > > Subject: Question about REBIND = message
> > >
> > > In the -18 rev, it is said that the = client send the REBIND
> > > message at T2
> > > (section 16.2) to 'any available = server' in order to extend the
> > > lifetimes of an IA, if the primary = server has not responded at T1. I
> > > guess 'any available server' means = any server which can receive the
> > > message (because it is onlink or via = a relay). However, according to
> > > section 13.4.4 the server can = successfully extend the
> > > lifetimes only if
> > > it has a binding for this = client.
> >
> > thats correct. the idea is if another = server thru some other means can do
> > this we don't want to prohibit the = function for rebind.

I disagree - I think there is an error in the -18 rev = of the DHCPv6
spec.  A server should silently discard any = Rebind messages to which it
cannot respond.  DHCPv4 leaves the decision = about whether to respond to a
DHCPREQUEST from a client in REBINDING state to loca = administrative control
(section 4.3.2 of RFC2131):

>       A DHCP = server MAY extend a client's lease only if it has local
>       = administrative authority to do so.

Implicitly, a DHCPv4 server may create a new binding = and extend the lease
of a previously unknown client if the server is = authorized to do so.

I suggest that the text in the DHCPv6 spec should be = changed to read:

   If the server cannot find a client entry = for this IA, the server
   MAY create a new binding for the IA and = send a Reply message to
   the client with the lease on the = IA.  If the server does not
   create a new binding it MUST silently = discard the Rebind message.

This text may need to be extended to specify that the = server may *only*
change the lease on the IA and *may not* make any = other changes to the
addresses assigned to the IA.

- Ralph


------_=_NextPart_001_01C0B03F.F27DC1D0-- From owner-dhcp-v6@bucknell.edu Mon Mar 19 01:46:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24231; Mon, 19 Mar 2001 01:46:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2J6kMe01587; Mon, 19 Mar 2001 01:46:22 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2J6kJe01711 for ; Mon, 19 Mar 2001 01:46:19 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2J6kIm09011 for ; Mon, 19 Mar 2001 00:46:18 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2J6kIj27716 for ; Mon, 19 Mar 2001 00:46:18 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Mar 19 00:46:17 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Mar 2001 00:48:06 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB875@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Question about REBIND message Date: Mon, 19 Mar 2001 00:48:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B040.8BFB6D80" 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 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_001_01C0B040.8BFB6D80 Content-Type: text/plain; charset="iso-8859-1" Ralph: If on a CONFIRM the server knows that the addresses have prefixes that don't exist on the link, can't the server tell that to the client? Or, must the client wait until some timeout time elapses before it can learn (or assume) it has moved to a new link? And, what if all of the DHCP servers are down - how can the client tell this from having moved to a new link? I would like to see a "BadPrefixes" or similar status. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, March 19, 2001 12:39 AM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: Question about REBIND message At 06:07 PM 3/14/2001 +0100, Jerome Labussiere wrote: >Still one dark point: About 'reacting immediately', I've the feeling >that it works with one DHCP server in the domain. But with two ? For >instance, if the client has a binding with server A. For a good reason, >it has to send a CONFIRM message. Server A and server B receive the >CONFIRM and answer. A returns a REPLY/status 0 and B returns a >REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by >the client and A's REPLY is received one or two ms after. If the client >reacts immediately, according to section 13.3.5, it has to assume that >the IA is lost and that it needs to notify the application layer and to >send a Request to reestablish an IA with B. The first REPLY is not >necessarily the best. I can't find anything in the spec about this. Jerome, You've identified a potential error in the DHCPv6 spec. The following text in 13.4.2 of the -18: > If the server cannot find a client entry for this IA the server > SHOULD return an empty IA with status set to NoBinding. is, IMHO, wrong. A server should ignore a CONFIRM message for which it has no information. IN DHCPv4, servers with no information about a binding do not respond to a request from a client to confirm the correctness of its address (DHCPREQUEST in INIT_REBOOT state). Here is the related text from DHCPv4, RC2131, section 3.2: > 2. Servers with knowledge of the client's configuration parameters > respond with a DHCPACK message to the client. Servers SHOULD NOT > check that the client's network address is already in use; the > client may respond to ICMP Echo Request messages at this point. > If the client's request is invalid (e.g., the client has moved > to a new subnet), servers SHOULD respond with a DHCPNAK message to > the client. Servers SHOULD NOT respond if their information is not > guaranteed to be accurate. For example, a server that identifies a > request for an expired binding that is owned by another server SHOULD > NOT respond with a DHCPNAK unless the servers are using an explicit > mechanism to maintain coherency among the servers. The text in 13.4.2 of the -18 rev of the DHCPv6 spec should read: > If the server cannot find a client entry for this IA the server > MUST silently discard the Confirm message. Ralph ------_=_NextPart_001_01C0B040.8BFB6D80 Content-Type: text/html; charset="iso-8859-1" RE: Question about REBIND message

Ralph:

If on a CONFIRM the server knows that the addresses have prefixes that
don't exist on the link, can't the server tell that to the client? Or,
must the client wait until some timeout time elapses before it can learn
(or assume) it has moved to a new link? And, what if all of the DHCP
servers are down - how can the client tell this from having moved to a
new link?

I would like to see a "BadPrefixes" or similar status.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, March 19, 2001 12:39 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: Question about REBIND message


At 06:07 PM 3/14/2001 +0100, Jerome Labussiere wrote:

>Still one dark point: About 'reacting immediately', I've the feeling
>that it works with one DHCP server in the domain. But with two ? For
>instance, if the client has a binding with server A. For a good reason,
>it has to send a CONFIRM message. Server A and server B receive the
>CONFIRM and answer. A returns a REPLY/status 0 and B returns a
>REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by
>the client and A's REPLY is received one or two ms after. If the client
>reacts immediately, according to section 13.3.5, it has to assume that
>the IA is lost and that it needs to notify the application layer and to
>send a Request to reestablish an IA with B. The first REPLY is not
>necessarily the best. I can't find anything in the spec about this.

Jerome,

You've identified a potential error in the DHCPv6 spec.  The following text
in 13.4.2 of the -18:

>    If the server cannot find a client entry for this IA the server
>    SHOULD return an empty IA with status set to NoBinding.

is, IMHO, wrong.  A server should ignore a CONFIRM message for which it has
no information.

IN DHCPv4, servers with no information about a binding do not respond to a
request from a client to confirm the correctness of its address
(DHCPREQUEST in INIT_REBOOT state).  Here is the related text from DHCPv4,
RC2131, section 3.2:

>    2. Servers with knowledge of the client's configuration parameters
>       respond with a DHCPACK message to the client.  Servers SHOULD NOT
>       check that the client's network address is already in use; the
>       client may respond to ICMP Echo Request messages at this point.
>       If the client's request is invalid (e.g., the client has moved
>       to a new subnet), servers SHOULD respond with a DHCPNAK message to
>       the client. Servers SHOULD NOT respond if their information is not
>       guaranteed to be accurate.  For example, a server that identifies a
>       request for an expired binding that is owned by another server SHOULD
>       NOT respond with a DHCPNAK unless the servers are using an explicit
>       mechanism to maintain coherency among the servers.

The text in 13.4.2 of the -18 rev of the DHCPv6 spec should read:

>    If the server cannot find a client entry for this IA the server
>    MUST silently discard the Confirm message.

Ralph

------_=_NextPart_001_01C0B040.8BFB6D80-- From owner-dhcp-v4@bucknell.edu Mon Mar 19 13:06:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17039 for ; Mon, 19 Mar 2001 13:06:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2JHw8e28541; Mon, 19 Mar 2001 12:58:16 -0500 (EST) 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 f2JHvwe28922 for ; Mon, 19 Mar 2001 12:57:58 -0500 (EST) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Mar 2001 10:03:13 -0800 Message-ID: <716D440F8C29D311991100A0C92048740106A561@GIDGET.INCOGNITO.COM> From: "Kostur, Andre" To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt Date: Mon, 19 Mar 2001 10:03:03 -0800 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 If I understand the draft correctly, implementation of this draft on client devices would require the DHCP client software to be permanently bound the DHCP client port on the device to listen for incoming DHCPReconfigure messages. Wouldn't this have the implication that other pieces of software on the device would not be able to send DHCP messages (and expect a response)? For example, a client device could not be on DHCP and still have some other piece of software which wants to get some configuration information by emitting DHCPINFORM packets since both the DHCP client, and this other software can't both be bound to the DHCP client port? From owner-dhcp-v4@bucknell.edu Mon Mar 19 13:15:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17267 for ; Mon, 19 Mar 2001 13:15:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2JIDVe02614; Mon, 19 Mar 2001 13:13:31 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2JIDJe02421 for ; Mon, 19 Mar 2001 13:13:19 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2JIDHm29893 for ; Mon, 19 Mar 2001 12:13:17 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2JIDHJ26940 for ; Mon, 19 Mar 2001 12:13:17 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Mar 19 12:13:17 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Mar 2001 12:15:04 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB87F@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt Date: Mon, 19 Mar 2001 12:15:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B0A0.83C4E9B0" Reply-To: Bernie.Volz@am1.ericsson.se 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_001_01C0B0A0.83C4E9B0 Content-Type: text/plain; charset="iso-8859-1" Yes, I believe that is correct. Is sharing the DHCP port really that useful and usual? It would be very difficult to predict when any of several clients might need to renew an address and thus sharing this port is problematic. Of course, it all depends on how robust you client software is and what it does if the port is in use (it might not even know that depending on the socket calls used and the implementation). If you also have multiple client programs running, only one would get the reconfigure event UNLESS you had some communication between the client & server to select the port on which reconfigures would be received. I think the general view is that you have ONE DHCP client application. An alternative might be to have the reconfigure sent to new well-known port and then a reconfigure client could be developed that used an O/S specific mannor to distribute the messages. But is this worth it? - Bernie Volz -----Original Message----- From: Kostur, Andre [mailto:Andre@incognito.com] Sent: Monday, March 19, 2001 1:03 PM To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt If I understand the draft correctly, implementation of this draft on client devices would require the DHCP client software to be permanently bound the DHCP client port on the device to listen for incoming DHCPReconfigure messages. Wouldn't this have the implication that other pieces of software on the device would not be able to send DHCP messages (and expect a response)? For example, a client device could not be on DHCP and still have some other piece of software which wants to get some configuration information by emitting DHCPINFORM packets since both the DHCP client, and this other software can't both be bound to the DHCP client port? ------_=_NextPart_001_01C0B0A0.83C4E9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt

Yes, I believe that is correct. Is sharing the DHCP = port really that useful and usual? It would be very difficult to = predict when any of several clients might need to renew an address and = thus sharing this port is problematic. Of course, it all depends on how = robust you client software is and what it does if the port is in use = (it might not even know that depending on the socket calls used and the = implementation).

If you also have multiple client programs running, = only one would get the reconfigure event UNLESS you had some = communication between the client & server to select the port on = which reconfigures would be received.

I think the general view is that you have ONE DHCP = client application.

An alternative might be to have the reconfigure sent = to new well-known port and then a reconfigure client could be developed = that used an O/S specific mannor to distribute the messages. But is = this worth it?

- Bernie Volz

-----Original Message-----
From: Kostur, Andre [mailto:Andre@incognito.com]
Sent: Monday, March 19, 2001 1:03 PM
To: DHCPv4 discussion list
Subject: RE: I-D = ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt


If I understand the draft correctly, implementation = of this draft on client
devices would require the DHCP client software to be = permanently bound the
DHCP client port on the device to listen for = incoming DHCPReconfigure
messages.  Wouldn't this have the implication = that other pieces of software
on the device would not be able to send DHCP = messages (and expect a
response)?  For example, a client device could = not be on DHCP and still have
some other piece of software which wants to get some = configuration
information by emitting DHCPINFORM packets since = both the DHCP client, and
this other software can't both be bound to the DHCP = client port?

------_=_NextPart_001_01C0B0A0.83C4E9B0-- From owner-dhcp-v4@bucknell.edu Mon Mar 19 15:34:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20899 for ; Mon, 19 Mar 2001 15:34:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2JKP4e23555; Mon, 19 Mar 2001 15:25:07 -0500 (EST) 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 f2JKP0e24564 for ; Mon, 19 Mar 2001 15:25:00 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.105.57]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2H85Xg02449; Sat, 17 Mar 2001 00:05:34 -0800 (PST) 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 f2JKOhT00389; Mon, 19 Mar 2001 14:24:43 -0600 (CST) Message-Id: <200103192024.f2JKOhT00389@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt In-Reply-To: Message from "Bernie Volz (EUD)" of "Mon, 19 Mar 2001 12:15:01 CST." <66F66129A77AD411B76200508B65AC694CB87F@eambunt705.ena-east.ericsson.se> Date: Mon, 19 Mar 2001 14:24:43 -0600 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Is sharing the DHCP port really that useful and usual? It would be > very difficult to predict when any of several clients might need to > renew an address and thus sharing this port is problematic. I believe this is how Microsoft currently does things. It's perfectly legitimate, although I have to admit that I was rather surprised to learn they'd done it that way - to me it makes more sense to have one client that talks to the wire and provide an API for other programs to use. Aside from allocating a new port, which I think is not a great idea, I don't see any way to solve this problem. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Mar 19 18:34:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25848; Mon, 19 Mar 2001 18:34:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2JNVce32440; Mon, 19 Mar 2001 18:31:39 -0500 (EST) Received: from web13315.mail.yahoo.com (web13315.mail.yahoo.com [216.136.175.51]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2JNVSe30471 for ; Mon, 19 Mar 2001 18:31:28 -0500 (EST) Message-ID: <20010319233127.9115.qmail@web13315.mail.yahoo.com> Received: from [135.222.64.52] by web13315.mail.yahoo.com; Mon, 19 Mar 2001 15:31:27 PST Date: Mon, 19 Mar 2001 15:31:27 -0800 (PST) From: Jarno Rajahalme Subject: DHCP option for SIP vs. for all SRV types in general To: DHCPv6 discussion list Cc: droms@bucknell.edu, schulzrinne@cs.columbia.edu, sip@lists.bell-labs.com, dhcp-v6@bucknell.edu 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 Hi, In the DHC meeting today I proposed defining a generic SRV DHC option, rather than separate DHC option for all services using DNS SRV records. In my opinion this would save a lot of work in future with new protocols, as there would not be any need to define new DHC options. In http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt the SIP DHC option is proposed. It is defined as simply:
     is just opportunistic.
 
 -ebi
   
 
----- Original Message -----
From:=20 Bernie Volz (EUD)
Sent: Sunday, March 18, 2001 = 10:29=20 PM
Subject: RE: why seperate Ia is = needed=20 for sending new Requests?

Why do we need a version number during DEVELOPMENT = of the=20 protocol. It
is pretty usual for I-Ds to = change over=20 time and that's just the price
you pay for=20 implementing early. I don't see a need to introduce a
version number during the development phase. We really need = to be=20 able
to maintain the flexibility to change = things=20 (though let's hope we're
only doing very = minor tweaks=20 now if any!).

I thought the original version number question was = raised=20 regarding the
longer term issue - post RFC = status how=20 to we evolve it from there
should we want = to. I guess=20 not.

 

    =20 Bernie

-----Original Message-----
From:=20 Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]=20
Sent: Friday, March 16, 2001 11:54 PM =
To: DHCPv6 discussion list
Subject: = RE: why=20 seperate Ia is needed for sending new Requests?


this is a good taxonomy for discussion point. =20 thanks.
I also don't think we should use a = port=20 number. I want to know from the
protocol the = version=20 has changed not by looking at the port number nor do I =
want to run different versions of dhcpv6.

/jim

> -----Original Message-----
>=20 From: ext Ebenezer Schubert [mailto:ebi@cup.hp.com] =
> Sent: Friday,March 16,2001 6:10 PM
>=20 To: DHCPv6 discussion list
> Subject: Re: = why=20 seperate Ia is needed for sending new Requests?
>=20
>
> = Hi,
>
> =       As=20 long as there is an agreement that any new
>=20 functionality starting
>=20       from  draft  revision =20 xxxx,  there  would be no
> = changes =20 to the msg
> =      =20 structure or the  interpretation  of existing  message=20
> types and any
>=20       new feature would be through the = introduction=20 of a new
> message type.
>       Then it is ok. =
>
> =       But=20 right  now,  there  seems to be a lot of  = changes. =20
> So  having a
>=20       version  no.  field,  = can help=20 to  start  the 
> = development =20 activity
>       = parallel=20 to the work in the IETF.
> =
>       This is the reason = why =20 revising  the  protocol  port
>=20 no.  would not
>=20       make any  sense,  = because  we=20 may not be able to 
> change  = port =20 nos,
>       = between=20 different  versions of the draft.  Also, we
> cannot gurantee,
>=20       that the interpretation of a particular = message=20 type
> will not change
>=20       until this becomes an RFC. =
>
> -ebi
>=20
>
> > = Ralph:=20
> >
> > Wish = I could=20 remember the details as well.
> >=20
> > I think one argument might be that = why not=20 just change the
> UDP port number if you = revise the=20 protocol?
> >
> >=20 Another is that by using a version number, you might not =
> gain that much because at least part of the message = format=20
> must stay the same in order to be able = to=20 recognize that this
> is a new version of = the=20 protocol.
> >
> >=20 And, a third possiblity is that since the message type is =
> the first byte, why not just use new message types?=20
> >
> = > And,=20 forth, future revisions of the protocol could be
>=20 handled by sending a special option on the Advertise or =
> Solicit to indicate that the server is capable of the=20
> extended functionality. Though in this = case, the=20 basic
> message format has to be = retained.=20
> >
> > BTW: = Regarding=20 the error message issue, how about we have a
>=20 message type which can be sent by a agent (server or relay) =
> to respond to a client to return some error. That way, = if the=20
> client sends an unknown message type, = the server=20 (or relay)
> can respond. This message = type MUST be=20 unicast by the relay
> or server. That = message type=20 might be formatted as follows:
> >=20
> = >      =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
> = >       0 1 2=20 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=20 8 9 0 1
> = >     =20
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >      = |   =20 msg-type   |  error-number = |     =20 error-text     
>          = |=20
> >     =20 = .            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
>          = .=20
> >     =20 = .            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
>          = .=20
> >     =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;    =20
>          = |=20
> >      =
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >
> > = Probably the only=20 error number that is needed today is
>=20 "unknown/unimplemented message type"?
> = >=20
> > - Bernie
> >=20
> > -----Original Message----- =
> > From: Ralph Droms [mailto:droms@bucknell.edu] =
> > Sent: Friday, March 16, 2001 5:11 = PM=20
> > To: DHCPv6 discussion list =
> > Subject: RE: why seperate Ia is needed for sending = new=20 Requests?
> >
> >=20
> > It's Friday afternoon, my wife's = been=20 visiting her mother
> in Wisconsin all=20
> > week and I'm rushing around = getting ready to=20 go to
> Minneapolis - so I'm =
> > having trouble remembering the details about = previous=20
> discussions about a
>=20 > version number in the DHCP message header.
>=20 >
> > But it strikes me that we = came to the=20 conclusion that a
> version number =
> > turns out to be not all that useful.  Does = anyone else=20
> remember having this
>=20 > discussion previously - it might have been regarding = DHCPv4?=20
> >
> > - = Ralph=20
> >
> > At = 03:25 PM=20 3/16/2001 -0600, Jim.Bound@nokia.com wrote:
> >=20 >I mean't to bring up the version number before.  We were=20
> asked for this some
>=20 > >time ago and a suggestion from several.  I can't recall=20
> arguments against it
>=20 > >and it may have fell through the cracks?
>=20 > >
> > >/jim =
> > >
> > > >=20 -----Original Message-----
> > > = > From:=20 ext ebenezer schubert [mailto:ebi@cup.hp.com] =
> > > > Sent: Friday,March 16,2001 3:12 PM =
> > > > To: DHCPv6 discussion list =
> > > > Subject: Re: why seperate Ia is needed = for sending=20 new Requests?
> > > > =
> > > >
> > > = >=20 Hi,
> > > >
>=20 > > >     I would agree with what Jim is = saying.=20 The market
> > > = >    =20 is ready for DHCPv6 and we need some conclusion
>=20 > > >     on this fast.
> > > >
> > >=20 >    At the same time there should be some scope = for=20
> > > >    whatever the = future=20 versions to interoperate with
> > > = >    the older ones. I would like to make 2=20 suggestions
> > > = >    in=20 this regard
> > > > =
> > > >     1. To have an = unimplemented=20 error message.
> > >=20 >     2. To have a version field in the = header.=20
> > > >
> = > >=20 >    So that even if the IESG takes a long time to=20 make
> > > >    a = standard.=20 We can proceed with the existing drafts,
> >=20 > >    if the standard is different from the = draft, we=20 should
> > > >    = be able=20 to handle them easily.
> > > = >=20
> > > >
> = > >=20 > -ebi
> > > > = Hewlett-Packard=20
> > > > 408-447-7652
>=20 > > >
> > > > ----- = Original=20 Message -----
> > > > From:=20 <Jim.Bound@nokia.com>
> > > = > To:=20 DHCPv6 discussion list <dhcp-v6@bucknell.edu>
> > > > Sent: Friday, March 16, 2001 7:50 = AM=20
> > > > Subject: RE: why seperate Ia is = needed=20 for sending new Requests?
> > > = >=20
> > > >
> = > >=20 > > hi ralph,
> > > > = >=20
> > > > > I agree with you in spirit = but the=20 flesh is weak.  we have
> > > = >=20 chased the
> > > > client =
> > > > > telling servers "I want x addresses" = for a=20 long time.  I
> > > > = suggest as=20 I
> > > > do for =
> > > > > reconf-init multicast we not permit = in our=20 effort to
> get to PS.  We =
> > > > will not
> = > >=20 > > reach consensus and the market is ready for dhcp =
> using ipv6. I also
> > = > >=20 believe
> > > > > reality is = that most=20 clients will get a default
> number of=20 addresses
> > > > from = the=20
> > > > > server.  clients that = send=20 another IA will get x
> addresses as = they=20
> > > > will be
> >=20 > > > special anyway.  So though in "theory" it seems=20
> messy, in practice I
>=20 > > > think
> > > > = > it will=20 work fine.
> > > > > =
> > > > > for temporary addresses I think the = client=20 setting a bit in
> > > > IA = Status=20
> > > > will
> >=20 > > > tell the server I need to "note" temporary addresses.=20
>  When the
> >=20 > > server
> > > > > = responds it=20 will send x addresses to the client.  Before
>=20 > > > each address
> > > = > a=20 bit
> > > > > will be set in = the addr=20 status field that this
> address is = "noted"=20 as
> > > > > temporary.  = I really=20 don't think temporary addresses
> is a=20 complex
> > > > thing and =
> > > > > I think we need to be careful we = don't over=20
> complicate this part of =
> > > > what we
> = > > >=20 > need to do.  at the server for the T1,T2,Preferred, and = Valid=20
> > > > lifetimes the
> > > > > server can apply the recommendations = of rfc=20 3041 to the
> > > > times it = uses=20
> > > > to
> > >=20 > > provide the client leases.  Pretty simplex stuff I=20
> think.  then we
>=20 > > > just need
> > > > = > to=20 make a decision on whether we let server renew temporary =
> > > > addresses.  in
>=20 > > > > the design call I think I heard it was ok to = extend the=20 valid
> > > > lifetime = but=20
> > > > > not the preferred = lifetime.  I=20 think we should be
> able to wrap = this=20
> > > > up at
> >=20 > > > minneapolis.
> > > = >=20 >
> > > > > what would be = really=20 useful for the wed dhcpv6 venue
> is if = ted=20 could
> > > > provide =
> > > > > the format and datum picture of the = IA +=20 client-id
> parts for the IA =
> > > > option
> = > > >=20 > and the text for forming it so we can discuss.  That=20
> is necessary to
> >=20 > > go to
> > > > > = last=20 call.  I think this is the most important and
> critical item we
> > = > > work=20 on
> > > > > next = week.=20
> > > > >
> >=20 > > > thanks
> > > > = >=20
> > > > > /jim
>=20 > > > >
> > > > > = >=20 -----Original Message-----
> > > = > >=20 > From: ext Ralph Droms [mailto:rdroms@cisco.com] =
> > > > > > Sent: Thursday,March 15,2001 = 7:57=20 PM
> > > > > > To: DHCPv6 = discussion=20 list
> > > > > > Cc: = DHCPv6=20 discussion list
> > > > > = > Subject:=20 RE: why seperate Ia is needed for sending
> new=20 Requests?
> > > > > = >=20
> > > > > >
>=20 > > > > > If I remember correctly, we've considered the = issue=20 of
> > > > > > virtual web = servers
> > > > > > in the = past.  Based on the capabilities of the current
> > > > > > version of HTTP for =
> > > > > > identifying virtual web servers = behind a=20 single IP address,
> > > > > = > we've=20 discarded
> > > > > > = virtual web=20 servers as a motivation for on-demand address
>=20 > > > assignment.
> > > = > >=20 >
> > > > > > That's = not to say=20 there aren't other motivations for
> > = > >=20 > > on-demand address
> > > = > >=20 > assignment.  Perhaps temporary addresses are a good =
> > > > > > motivating example.  = If=20
> > > > > > we're going to add = complexity=20 to the protocol to support
> > > = > >=20 > on-demand address
> > > > = > >=20 assignment, we need to make sure we understand the specific =
> > > > > > motivations and =
> > > > > > requirements.
> > > > > >
> = > >=20 > > > - Ralph
> > > > = >=20 >
> > > > > > At 07:31 = AM=20 3/15/2001 -0800, Thirumalesh Bhat wrote:
> >=20 > > > > >It is entirely possible for a client to ask = for=20 more
> > > > > > "normal"=20 addresses.
> > > > > > = >The=20 reason being in IPv4, addresses were a bottle neck and =
> > > > > > in IPv6 it wont =
> > > > > > >be. A server that does web = hosting=20 may need thousands of IP
> > > > = > >=20 addresses and
> > > > > > = >it may=20 not be possible to know the requirement
> = ahead of=20 time
> > > > > > in all=20 cases.
> > > > > > >It = will=20 contact the DHCP Server to request more IP
>=20 addresses
> > > > > > in = this=20 case
> > > > > > >or = use=20 stateless config to generate the IPs it needs. A
>=20 > > > > > server hosting
> = > >=20 > > > >different services may want to use different=20 "normal"
> > > > > > = addresses for=20 each
> > > > > > = >service.=20
> > > > > >
>=20 > > > > >
> > > > = >=20 >
> > > > > =
> > > >
>=20

------=_NextPart_000_0022_01C0B111.0D7E1120-- From owner-dhcp-v6@bucknell.edu Tue Mar 20 20:37:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06614; Tue, 20 Mar 2001 20:37:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2L1Xfe06345; Tue, 20 Mar 2001 20:33:41 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2L1XUe11013 for ; Tue, 20 Mar 2001 20:33:30 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2L1XSm21803 for ; Tue, 20 Mar 2001 19:33:29 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2L1XSw07705 for ; Tue, 20 Mar 2001 19:33:28 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Mar 20 19:33:28 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Mar 2001 19:35:17 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB88D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? Date: Tue, 20 Mar 2001 19:35:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B1A7.2E5326B0" 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 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_001_01C0B1A7.2E5326B0 Content-Type: text/plain; charset="iso-8859-1" Ebi: The post RFC makes more sense. Though I think history has shown that it often isn't that useful (an exception is probably the IP header version field!). I think there are plenty of other alternatives - such as using new message numbers, a new port number if really different, or perhaps even just options. So, the question becomes is it worth paying the price for a byte (or at least a few bits if we can find them). - Bernie -----Original Message----- From: ebenezer schubert [mailto:ebi@cup.hp.com] Sent: Tuesday, March 20, 2001 10:41 AM To: DHCPv6 discussion list Subject: Re: why seperate Ia is needed for sending new Requests? Hi Bernie, The reason for asking version number is not only for DEVOLOPMENT of the protocol. It is also post RFC. The suggestion to use it during the development is just opportunistic. -ebi ----- Original Message ----- From: Bernie Volz (EUD) To: DHCPv6 discussion list Sent: Sunday, March 18, 2001 10:29 PM Subject: RE: why seperate Ia is needed for sending new Requests? Why do we need a version number during DEVELOPMENT of the protocol. It is pretty usual for I-Ds to change over time and that's just the price you pay for implementing early. I don't see a need to introduce a version number during the development phase. We really need to be able to maintain the flexibility to change things (though let's hope we're only doing very minor tweaks now if any!). I thought the original version number question was raised regarding the longer term issue - post RFC status how to we evolve it from there should we want to. I guess not. Bernie -----Original Message----- From: Jim.Bound@nokia.com [ mailto:Jim.Bound@nokia.com ] Sent: Friday, March 16, 2001 11:54 PM To: DHCPv6 discussion list Subject: RE: why seperate Ia is needed for sending new Requests? this is a good taxonomy for discussion point. thanks. I also don't think we should use a port number. I want to know from the protocol the version has changed not by looking at the port number nor do I want to run different versions of dhcpv6. /jim > -----Original Message----- > From: ext Ebenezer Schubert [ mailto:ebi@cup.hp.com ] > Sent: Friday,March 16,2001 6:10 PM > To: DHCPv6 discussion list > Subject: Re: why seperate Ia is needed for sending new Requests? > > > Hi, > > As long as there is an agreement that any new > functionality starting > from draft revision xxxx, there would be no > changes to the msg > structure or the interpretation of existing message > types and any > new feature would be through the introduction of a new > message type. > Then it is ok. > > But right now, there seems to be a lot of changes. > So having a > version no. field, can help to start the > development activity > parallel to the work in the IETF. > > This is the reason why revising the protocol port > no. would not > make any sense, because we may not be able to > change port nos, > between different versions of the draft. Also, we > cannot gurantee, > that the interpretation of a particular message type > will not change > until this becomes an RFC. > > -ebi > > > > Ralph: > > > > Wish I could remember the details as well. > > > > I think one argument might be that why not just change the > UDP port number if you revise the protocol? > > > > Another is that by using a version number, you might not > gain that much because at least part of the message format > must stay the same in order to be able to recognize that this > is a new version of the protocol. > > > > And, a third possiblity is that since the message type is > the first byte, why not just use new message types? > > > > And, forth, future revisions of the protocol could be > handled by sending a special option on the Advertise or > Solicit to indicate that the server is capable of the > extended functionality. Though in this case, the basic > message format has to be retained. > > > > BTW: Regarding the error message issue, how about we have a > message type which can be sent by a agent (server or relay) > to respond to a client to return some error. That way, if the > client sends an unknown message type, the server (or relay) > can respond. This message type MUST be unicast by the relay > or server. That message type might be formatted as follows: > > > > 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 | error-number | error-text > | > > . > . > > . > . > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Probably the only error number that is needed today is > "unknown/unimplemented message type"? > > > > - Bernie > > > > -----Original Message----- > > From: Ralph Droms [ mailto:droms@bucknell.edu ] > > Sent: Friday, March 16, 2001 5:11 PM > > To: DHCPv6 discussion list > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > It's Friday afternoon, my wife's been visiting her mother > in Wisconsin all > > week and I'm rushing around getting ready to go to > Minneapolis - so I'm > > having trouble remembering the details about previous > discussions about a > > version number in the DHCP message header. > > > > But it strikes me that we came to the conclusion that a > version number > > turns out to be not all that useful. Does anyone else > remember having this > > discussion previously - it might have been regarding DHCPv4? > > > > - Ralph > > > > At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote: > > >I mean't to bring up the version number before. We were > asked for this some > > >time ago and a suggestion from several. I can't recall > arguments against it > > >and it may have fell through the cracks? > > > > > >/jim > > > > > > > -----Original Message----- > > > > From: ext ebenezer schubert [ mailto:ebi@cup.hp.com ] > > > > Sent: Friday,March 16,2001 3:12 PM > > > > To: DHCPv6 discussion list > > > > Subject: Re: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > Hi, > > > > > > > > I would agree with what Jim is saying. The market > > > > is ready for DHCPv6 and we need some conclusion > > > > on this fast. > > > > > > > > At the same time there should be some scope for > > > > whatever the future versions to interoperate with > > > > the older ones. I would like to make 2 suggestions > > > > in this regard > > > > > > > > 1. To have an unimplemented error message. > > > > 2. To have a version field in the header. > > > > > > > > So that even if the IESG takes a long time to make > > > > a standard. We can proceed with the existing drafts, > > > > if the standard is different from the draft, we should > > > > be able to handle them easily. > > > > > > > > > > > > -ebi > > > > Hewlett-Packard > > > > 408-447-7652 > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: DHCPv6 discussion list > > > > Sent: Friday, March 16, 2001 7:50 AM > > > > Subject: RE: why seperate Ia is needed for sending new Requests? > > > > > > > > > > > > > hi ralph, > > > > > > > > > > I agree with you in spirit but the flesh is weak. we have > > > > chased the > > > > client > > > > > telling servers "I want x addresses" for a long time. I > > > > suggest as I > > > > do for > > > > > reconf-init multicast we not permit in our effort to > get to PS. We > > > > will not > > > > > reach consensus and the market is ready for dhcp > using ipv6. I also > > > > believe > > > > > reality is that most clients will get a default > number of addresses > > > > from the > > > > > server. clients that send another IA will get x > addresses as they > > > > will be > > > > > special anyway. So though in "theory" it seems > messy, in practice I > > > > think > > > > > it will work fine. > > > > > > > > > > for temporary addresses I think the client setting a bit in > > > > IA Status > > > > will > > > > > tell the server I need to "note" temporary addresses. > When the > > > > server > > > > > responds it will send x addresses to the client. Before > > > > each address > > > > a bit > > > > > will be set in the addr status field that this > address is "noted" as > > > > > temporary. I really don't think temporary addresses > is a complex > > > > thing and > > > > > I think we need to be careful we don't over > complicate this part of > > > > what we > > > > > need to do. at the server for the T1,T2,Preferred, and Valid > > > > lifetimes the > > > > > server can apply the recommendations of rfc 3041 to the > > > > times it uses > > > > to > > > > > provide the client leases. Pretty simplex stuff I > think. then we > > > > just need > > > > > to make a decision on whether we let server renew temporary > > > > addresses. in > > > > > the design call I think I heard it was ok to extend the valid > > > > lifetime but > > > > > not the preferred lifetime. I think we should be > able to wrap this > > > > up at > > > > > minneapolis. > > > > > > > > > > what would be really useful for the wed dhcpv6 venue > is if ted could > > > > provide > > > > > the format and datum picture of the IA + client-id > parts for the IA > > > > option > > > > > and the text for forming it so we can discuss. That > is necessary to > > > > go to > > > > > last call. I think this is the most important and > critical item we > > > > work on > > > > > next week. > > > > > > > > > > thanks > > > > > > > > > > /jim > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Ralph Droms [ mailto:rdroms@cisco.com ] > > > > > > Sent: Thursday,March 15,2001 7:57 PM > > > > > > To: DHCPv6 discussion list > > > > > > Cc: DHCPv6 discussion list > > > > > > Subject: RE: why seperate Ia is needed for sending > new Requests? > > > > > > > > > > > > > > > > > > If I remember correctly, we've considered the issue of > > > > > > virtual web servers > > > > > > in the past. Based on the capabilities of the current > > > > > > version of HTTP for > > > > > > identifying virtual web servers behind a single IP address, > > > > > > we've discarded > > > > > > virtual web servers as a motivation for on-demand address > > > > assignment. > > > > > > > > > > > > That's not to say there aren't other motivations for > > > > > > on-demand address > > > > > > assignment. Perhaps temporary addresses are a good > > > > > > motivating example. If > > > > > > we're going to add complexity to the protocol to support > > > > > > on-demand address > > > > > > assignment, we need to make sure we understand the specific > > > > > > motivations and > > > > > > requirements. > > > > > > > > > > > > - Ralph > > > > > > > > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote: > > > > > > >It is entirely possible for a client to ask for more > > > > > > "normal" addresses. > > > > > > >The reason being in IPv4, addresses were a bottle neck and > > > > > > in IPv6 it wont > > > > > > >be. A server that does web hosting may need thousands of IP > > > > > > addresses and > > > > > > >it may not be possible to know the requirement > ahead of time > > > > > > in all cases. > > > > > > >It will contact the DHCP Server to request more IP > addresses > > > > > > in this case > > > > > > >or use stateless config to generate the IPs it needs. A > > > > > > server hosting > > > > > > >different services may want to use different "normal" > > > > > > addresses for each > > > > > > >service. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0B1A7.2E5326B0 Content-Type: text/html; charset="iso-8859-1" RE: why seperate Ia is needed for sending new Requests?
Ebi:
 
The post RFC makes more sense. Though I think history has shown that it often isn't that useful (an exception is probably the IP header version field!).
 
I think there are plenty of other alternatives - such as using new message numbers, a new port number if really different, or perhaps even just options. So, the question becomes is it worth paying the price for a byte (or at least a few bits if we can find them).
 
- Bernie
-----Original Message-----
From: ebenezer schubert [mailto:ebi@cup.hp.com]
Sent: Tuesday, March 20, 2001 10:41 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests?

Hi Bernie,
   
    The reason for asking version number is
    not only for DEVOLOPMENT of the protocol.
    It is also post RFC.
 
    The suggestion to use it during the development
     is just opportunistic.
 
 -ebi
   
 
----- Original Message -----
Sent: Sunday, March 18, 2001 10:29 PM
Subject: RE: why seperate Ia is needed for sending new Requests?

Why do we need a version number during DEVELOPMENT of the protocol. It
is pretty usual for I-Ds to change over time and that's just the price
you pay for implementing early. I don't see a need to introduce a
version number during the development phase. We really need to be able
to maintain the flexibility to change things (though let's hope we're
only doing very minor tweaks now if any!).

I thought the original version number question was raised regarding the
longer term issue - post RFC status how to we evolve it from there
should we want to. I guess not.

 

     Bernie

-----Original Message-----
From: Jim.Bound@nokia.com [mailto:Jim.Bound@nokia.com]
Sent: Friday, March 16, 2001 11:54 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?


this is a good taxonomy for discussion point.  thanks.
I also don't think we should use a port number. I want to know from the
protocol the version has changed not by looking at the port number nor do I
want to run different versions of dhcpv6.

/jim

> -----Original Message-----
> From: ext Ebenezer Schubert [mailto:ebi@cup.hp.com]
> Sent: Friday,March 16,2001 6:10 PM
> To: DHCPv6 discussion list
> Subject: Re: why seperate Ia is needed for sending new Requests?
>
>
> Hi,
>
>       As long as there is an agreement that any new
> functionality starting
>       from  draft  revision  xxxx,  there  would be no
> changes  to the msg
>       structure or the  interpretation  of existing  message
> types and any
>       new feature would be through the introduction of a new
> message type.
>       Then it is ok.
>
>       But right  now,  there  seems to be a lot of  changes. 
> So  having a
>       version  no.  field,  can help to  start  the 
> development  activity
>       parallel to the work in the IETF.
>
>       This is the reason why  revising  the  protocol  port
> no.  would not
>       make any  sense,  because  we may not be able to 
> change  port  nos,
>       between different  versions of the draft.  Also, we
> cannot gurantee,
>       that the interpretation of a particular message type
> will not change
>       until this becomes an RFC.
>
> -ebi
>
>
> > Ralph:
> >
> > Wish I could remember the details as well.
> >
> > I think one argument might be that why not just change the
> UDP port number if you revise the protocol?
> >
> > Another is that by using a version number, you might not
> gain that much because at least part of the message format
> must stay the same in order to be able to recognize that this
> is a new version of the protocol.
> >
> > And, a third possiblity is that since the message type is
> the first byte, why not just use new message types?
> >
> > And, forth, future revisions of the protocol could be
> handled by sending a special option on the Advertise or
> Solicit to indicate that the server is capable of the
> extended functionality. Though in this case, the basic
> message format has to be retained.
> >
> > BTW: Regarding the error message issue, how about we have a
> message type which can be sent by a agent (server or relay)
> to respond to a client to return some error. That way, if the
> client sends an unknown message type, the server (or relay)
> can respond. This message type MUST be unicast by the relay
> or server. That message type might be formatted as follows:
> >
> >       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   |  error-number |      error-text     
>          |
> >      .                                                     
>          .
> >      .                                                     
>          .
> >      |                                                     
>          |
> >     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Probably the only error number that is needed today is
> "unknown/unimplemented message type"?
> >
> > - Bernie
> >
> > -----Original Message-----
> > From: Ralph Droms [mailto:droms@bucknell.edu]
> > Sent: Friday, March 16, 2001 5:11 PM
> > To: DHCPv6 discussion list
> > Subject: RE: why seperate Ia is needed for sending new Requests?
> >
> >
> > It's Friday afternoon, my wife's been visiting her mother
> in Wisconsin all
> > week and I'm rushing around getting ready to go to
> Minneapolis - so I'm
> > having trouble remembering the details about previous
> discussions about a
> > version number in the DHCP message header.
> >
> > But it strikes me that we came to the conclusion that a
> version number
> > turns out to be not all that useful.  Does anyone else
> remember having this
> > discussion previously - it might have been regarding DHCPv4?
> >
> > - Ralph
> >
> > At 03:25 PM 3/16/2001 -0600, Jim.Bound@nokia.com wrote:
> > >I mean't to bring up the version number before.  We were
> asked for this some
> > >time ago and a suggestion from several.  I can't recall
> arguments against it
> > >and it may have fell through the cracks?
> > >
> > >/jim
> > >
> > > > -----Original Message-----
> > > > From: ext ebenezer schubert [mailto:ebi@cup.hp.com]
> > > > Sent: Friday,March 16,2001 3:12 PM
> > > > To: DHCPv6 discussion list
> > > > Subject: Re: why seperate Ia is needed for sending new Requests?
> > > >
> > > >
> > > > Hi,
> > > >
> > > >     I would agree with what Jim is saying. The market
> > > >     is ready for DHCPv6 and we need some conclusion
> > > >     on this fast.
> > > >
> > > >    At the same time there should be some scope for
> > > >    whatever the future versions to interoperate with
> > > >    the older ones. I would like to make 2 suggestions
> > > >    in this regard
> > > >
> > > >     1. To have an unimplemented error message.
> > > >     2. To have a version field in the header.
> > > >
> > > >    So that even if the IESG takes a long time to make
> > > >    a standard. We can proceed with the existing drafts,
> > > >    if the standard is different from the draft, we should
> > > >    be able to handle them easily.
> > > >
> > > >
> > > > -ebi
> > > > Hewlett-Packard
> > > > 408-447-7652
> > > >
> > > > ----- Original Message -----
> > > > From: <Jim.Bound@nokia.com>
> > > > To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
> > > > Sent: Friday, March 16, 2001 7:50 AM
> > > > Subject: RE: why seperate Ia is needed for sending new Requests?
> > > >
> > > >
> > > > > hi ralph,
> > > > >
> > > > > I agree with you in spirit but the flesh is weak.  we have
> > > > chased the
> > > > client
> > > > > telling servers "I want x addresses" for a long time.  I
> > > > suggest as I
> > > > do for
> > > > > reconf-init multicast we not permit in our effort to
> get to PS.  We
> > > > will not
> > > > > reach consensus and the market is ready for dhcp
> using ipv6. I also
> > > > believe
> > > > > reality is that most clients will get a default
> number of addresses
> > > > from the
> > > > > server.  clients that send another IA will get x
> addresses as they
> > > > will be
> > > > > special anyway.  So though in "theory" it seems
> messy, in practice I
> > > > think
> > > > > it will work fine.
> > > > >
> > > > > for temporary addresses I think the client setting a bit in
> > > > IA Status
> > > > will
> > > > > tell the server I need to "note" temporary addresses.
>  When the
> > > > server
> > > > > responds it will send x addresses to the client.  Before
> > > > each address
> > > > a bit
> > > > > will be set in the addr status field that this
> address is "noted" as
> > > > > temporary.  I really don't think temporary addresses
> is a complex
> > > > thing and
> > > > > I think we need to be careful we don't over
> complicate this part of
> > > > what we
> > > > > need to do.  at the server for the T1,T2,Preferred, and Valid
> > > > lifetimes the
> > > > > server can apply the recommendations of rfc 3041 to the
> > > > times it uses
> > > > to
> > > > > provide the client leases.  Pretty simplex stuff I
> think.  then we
> > > > just need
> > > > > to make a decision on whether we let server renew temporary
> > > > addresses.  in
> > > > > the design call I think I heard it was ok to extend the valid
> > > > lifetime but
> > > > > not the preferred lifetime.  I think we should be
> able to wrap this
> > > > up at
> > > > > minneapolis.
> > > > >
> > > > > what would be really useful for the wed dhcpv6 venue
> is if ted could
> > > > provide
> > > > > the format and datum picture of the IA + client-id
> parts for the IA
> > > > option
> > > > > and the text for forming it so we can discuss.  That
> is necessary to
> > > > go to
> > > > > last call.  I think this is the most important and
> critical item we
> > > > work on
> > > > > next week.
> > > > >
> > > > > thanks
> > > > >
> > > > > /jim
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Ralph Droms [mailto:rdroms@cisco.com]
> > > > > > Sent: Thursday,March 15,2001 7:57 PM
> > > > > > To: DHCPv6 discussion list
> > > > > > Cc: DHCPv6 discussion list
> > > > > > Subject: RE: why seperate Ia is needed for sending
> new Requests?
> > > > > >
> > > > > >
> > > > > > If I remember correctly, we've considered the issue of
> > > > > > virtual web servers
> > > > > > in the past.  Based on the capabilities of the current
> > > > > > version of HTTP for
> > > > > > identifying virtual web servers behind a single IP address,
> > > > > > we've discarded
> > > > > > virtual web servers as a motivation for on-demand address
> > > > assignment.
> > > > > >
> > > > > > That's not to say there aren't other motivations for
> > > > > > on-demand address
> > > > > > assignment.  Perhaps temporary addresses are a good
> > > > > > motivating example.  If
> > > > > > we're going to add complexity to the protocol to support
> > > > > > on-demand address
> > > > > > assignment, we need to make sure we understand the specific
> > > > > > motivations and
> > > > > > requirements.
> > > > > >
> > > > > > - Ralph
> > > > > >
> > > > > > At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote:
> > > > > > >It is entirely possible for a client to ask for more
> > > > > > "normal" addresses.
> > > > > > >The reason being in IPv4, addresses were a bottle neck and
> > > > > > in IPv6 it wont
> > > > > > >be. A server that does web hosting may need thousands of IP
> > > > > > addresses and
> > > > > > >it may not be possible to know the requirement
> ahead of time
> > > > > > in all cases.
> > > > > > >It will contact the DHCP Server to request more IP
> addresses
> > > > > > in this case
> > > > > > >or use stateless config to generate the IPs it needs. A
> > > > > > server hosting
> > > > > > >different services may want to use different "normal"
> > > > > > addresses for each
> > > > > > >service.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
>

------_=_NextPart_001_01C0B1A7.2E5326B0-- From owner-dhcp-v4@bucknell.edu Wed Mar 21 05:40:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12877 for ; Wed, 21 Mar 2001 05:40:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LAY1e26711; Wed, 21 Mar 2001 05:34:01 -0500 (EST) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2LAXee02397 for ; Wed, 21 Mar 2001 05:33:40 -0500 (EST) Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Wed, 21 Mar 2001 10:32:55 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <1PP8KSXM>; Wed, 21 Mar 2001 10:29:59 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207A0A6E6@mbtlipnt02.btlabs.bt.co.uk> From: nick.farrow@bt.com To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt Date: Wed, 21 Mar 2001 10:29:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Reply-To: nick.farrow@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN [>] Yes, I believe that is correct. Is sharing the DHCP port really that useful and usual? It [>] would be very difficult to predict when any of several clients might need to renew an [>] address and thus sharing this port is problematic. Of course, it all depends on how [>] robust you client software is and what it does if the port is in use (it might not even [>] know that depending on the socket calls used and the implementation). [>] If you also have multiple client programs running, only one would get the reconfigure [>] event UNLESS you had some communication between the client & server to select [>] the port on which reconfigures would be received. [>] I think the general view is that you have ONE DHCP client application. [>] I think it boils down to implementation. For instance they could have a kernel network driver that sits just above the network card, but below ip, that snifs dhcp traffic ( well known port). This could be wrapped in a com object at the application layer that can then acts as provider of dhcp traffic/signals for other objects, get address object, renew object, reconfigure ..... In that case a single port makes sense. nick From owner-dhcp-v4@bucknell.edu Wed Mar 21 11:14:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27961 for ; Wed, 21 Mar 2001 11:14:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LG6Pe05939; Wed, 21 Mar 2001 11:06:25 -0500 (EST) Received: from tcp_local-daemon (ns.megamail.pt [193.236.127.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2LG6Ie15068 for ; Wed, 21 Mar 2001 11:06:18 -0500 (EST) Received: from web.megamail.pt by smtp.megamail.pt (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GAK00E6322BE3@smtp.megamail.pt> for dhcp-v4@bucknell.edu; Wed, 21 Mar 2001 16:06:12 +0000 (GMT) Date: Wed, 21 Mar 2001 16:06:11 +0000 From: Joao Santos Subject: Settings configured with DHCP To: DHCPv4 discussion list Message-id: <985190771.3ab8d1739a1a0@paris-hme1> MIME-version: 1.0 Content-type: text/plain User-Agent: IMP/PHP IMAP webmail program X-Originating-IP: 193.136.203.26 X-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-HTTP-VIA: 1.1 cache X-HTTP-X-FORWARDED_FOR: 193.137.209.4 X-Cache-Control: bypass-client=193.137.209.4 Reply-To: zaskar@megamail.pt Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-MIME-Autoconverted: from 8bit to quoted-printable by mail.bucknell.edu id f2LG6Pe05939 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA27961 Hello! When you use a DHCP server, a client is informed of what IP address it can use, and who is the DNS server, right? Is there any way to also automatically configure a proxy server? When a client connects to the DHCP server it would also receive the information of what proxy server to use... is this even possible? Regards, Joao Santos ------------------------------------------------- Email Enviado utilizando o serviço MegaMail From owner-dhcp-v6@bucknell.edu Wed Mar 21 11:39:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29141; Wed, 21 Mar 2001 11:39:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LGc4e28307; Wed, 21 Mar 2001 11:38:04 -0500 (EST) 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 f2LGbpe03641 for ; Wed, 21 Mar 2001 11:37:51 -0500 (EST) Received: from grosse.bisbee.fugue.com (pcp001452pcs.wireless.meeting.ietf.org [135.222.67.184]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2J4ISE03422 for ; Sun, 18 Mar 2001 20:18:29 -0800 (PST) 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 f2LGbW300493 for ; Wed, 21 Mar 2001 10:37:32 -0600 (CST) Message-Id: <200103211637.f2LGbW300493@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: DUID privacy issues Date: Wed, 21 Mar 2001 10:37:32 -0600 From: Ted Lemon 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 brought up the issue that DUIDs could be snooped on the local network and used to violate the privacy of the owner of the DUID. I'd like to solve this, but the problem is that the DUID needs to be fixed, not variable. We don't have a shared secret on the server. I don't really see any way to obscure the DUID and allow it to continue to function. Does anybody have any suggestions? If the answer is no, I think we should just explicitly say "we aren't solving this problem." We *can* insist that the DUID be obscured if it is published - I just don't see how to obscure it on the wire. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Mar 21 14:40:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09389 for ; Wed, 21 Mar 2001 14:40:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LJXbe14539; Wed, 21 Mar 2001 14:33:37 -0500 (EST) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch2.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2LJXVe17973 for ; Wed, 21 Mar 2001 14:33:32 -0500 (EST) Received: by fs-sd-exch2.coppermountain.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Mar 2001 11:33:37 -0800 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C8032C7869@fs-sd-exch2.coppermountain.com> From: emichelsen@coppermountain.com To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt Date: Wed, 21 Mar 2001 11:33:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I don't understand this issue. Applications don't renew an address. Applications don't usually know anything about how an address (or any other IP parameter) was assigned: static, manual, DHCP, IPCP, etc. I don't see any reason for an application to use the DHCP port. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: nick.farrow@bt.com [mailto:nick.farrow@bt.com] > Sent: Wednesday, March 21, 2001 2:30 > To: DHCPv4 discussion list > Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt > > > > [>] Yes, I believe that is correct. Is sharing the DHCP port > really that useful and usual? It [>] would be very > difficult to predict > when any of several clients might need to renew an [>] > address and thus > sharing this port is problematic. Of course, it all depends on how [>] > robust you client software is and what it does if the port is > in use (it > might not even [>] know that depending on the socket calls > used and the > implementation). > > [>] If you also have multiple client programs > running, only one > would get the reconfigure [>] event UNLESS you had some > communication > between the client & server to select [>] the port on > which reconfigures > would be received. > > [>] I think the general view is that you have ONE DHCP client > application. > [>] > > I think it boils down to implementation. For instance they could > have a kernel network driver that sits just above the network > card, but > below ip, that snifs dhcp traffic ( well known port). This > could be wrapped > in a com object at the application layer that can then acts > as provider of > dhcp traffic/signals for other objects, get address object, > renew object, > reconfigure ..... In that case a single port makes sense. > > nick > > From owner-dhcp-v4@bucknell.edu Wed Mar 21 14:42:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09539 for ; Wed, 21 Mar 2001 14:42:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LJfje15866; Wed, 21 Mar 2001 14:41:45 -0500 (EST) 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 f2LJfXe23101 for ; Wed, 21 Mar 2001 14:41:34 -0500 (EST) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Mar 2001 11:46:35 -0800 Message-ID: <716D440F8C29D311991100A0C92048740106A578@GIDGET.INCOGNITO.COM> From: "Kostur, Andre" To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt Date: Wed, 21 Mar 2001 11:46:34 -0800 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 Hey Eric :) What about application software on the device which needs data from the DHCP Options list which aren't recognized by the DHCP Client software on the box. Couldn't such software emit a DHCPINFORM packet to the DHCP server to get the set of options back, and parse out the options of interest to the application? Now this does assume that the DHCP client software doesn't put the complete set of options that it received from the DHCP server into a location where other applications may retrieve the data. If the client software only keeps the options of interest to it, then the other data would be lost. -----Original Message----- From: emichelsen@coppermountain.com [mailto:emichelsen@coppermountain.com] Sent: Wednesday, March 21, 2001 11:33 AM To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt I don't understand this issue. Applications don't renew an address. Applications don't usually know anything about how an address (or any other IP parameter) was assigned: static, manual, DHCP, IPCP, etc. I don't see any reason for an application to use the DHCP port. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: nick.farrow@bt.com [mailto:nick.farrow@bt.com] > Sent: Wednesday, March 21, 2001 2:30 > To: DHCPv4 discussion list > Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt > > > > [>] Yes, I believe that is correct. Is sharing the DHCP port > really that useful and usual? It [>] would be very > difficult to predict > when any of several clients might need to renew an [>] > address and thus > sharing this port is problematic. Of course, it all depends on how [>] > robust you client software is and what it does if the port is > in use (it > might not even [>] know that depending on the socket calls > used and the > implementation). > > [>] If you also have multiple client programs > running, only one > would get the reconfigure [>] event UNLESS you had some > communication > between the client & server to select [>] the port on > which reconfigures > would be received. > > [>] I think the general view is that you have ONE DHCP client > application. > [>] > > I think it boils down to implementation. For instance they could > have a kernel network driver that sits just above the network > card, but > below ip, that snifs dhcp traffic ( well known port). This > could be wrapped > in a com object at the application layer that can then acts > as provider of > dhcp traffic/signals for other objects, get address object, > renew object, > reconfigure ..... In that case a single port makes sense. > > nick > > From owner-dhcp-v4@bucknell.edu Wed Mar 21 14:48:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09886 for ; Wed, 21 Mar 2001 14:48:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LJlNe13231; Wed, 21 Mar 2001 14:47:23 -0500 (EST) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch2.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2LJlLe23509 for ; Wed, 21 Mar 2001 14:47:21 -0500 (EST) Received: by fs-sd-exch2.coppermountain.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Mar 2001 11:47:26 -0800 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C8032C786A@fs-sd-exch2.coppermountain.com> From: emichelsen@coppermountain.com To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt Date: Wed, 21 Mar 2001 11:47:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN That's a plausible scenario (but notably different from the one discussed below about "applications renewing an IP address"). While plausible, though, it seems pretty rare to me. I guess the question is: how much restriction do we allow in the protocol development to accomodate limited implementations of the past that might or might not be deployed? ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Kostur, Andre [mailto:Andre@incognito.com] > Sent: Wednesday, March 21, 2001 11:47 > To: Eric Michelsen; DHCPv4 discussion list > Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt > > > Hey Eric :) > > What about application software on the device which needs > data from the DHCP > Options list which aren't recognized by the DHCP Client > software on the box. > Couldn't such software emit a DHCPINFORM packet to the DHCP > server to get > the set of options back, and parse out the options of interest to the > application? Now this does assume that the DHCP client > software doesn't put > the complete set of options that it received from the DHCP > server into a > location where other applications may retrieve the data. If > the client > software only keeps the options of interest to it, then the > other data would > be lost. > > -----Original Message----- > From: emichelsen@coppermountain.com > [mailto:emichelsen@coppermountain.com] > Sent: Wednesday, March 21, 2001 11:33 AM > To: DHCPv4 discussion list > Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt > > > I don't understand this issue. Applications don't renew an address. > Applications don't usually know anything about how an address > (or any other > IP parameter) was assigned: static, manual, DHCP, IPCP, etc. > I don't see > any reason for an application to use the DHCP port. > ------------------------------------------- > Eric L. Michelsen, Copper Mountain Networks > > > > -----Original Message----- > > From: nick.farrow@bt.com [mailto:nick.farrow@bt.com] > > Sent: Wednesday, March 21, 2001 2:30 > > To: DHCPv4 discussion list > > Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt > > > > > > > > [>] Yes, I believe that is correct. Is sharing the DHCP port > > really that useful and usual? It [>] would be very > > difficult to predict > > when any of several clients might need to renew an [>] > > address and thus > > sharing this port is problematic. Of course, it all depends > on how [>] > > robust you client software is and what it does if the port is > > in use (it > > might not even [>] know that depending on the socket calls > > used and the > > implementation). > > > > [>] If you also have multiple client programs > > running, only one > > would get the reconfigure [>] event UNLESS you had some > > communication > > between the client & server to select [>] the port on > > which reconfigures > > would be received. > > > > [>] I think the general view is that you have ONE DHCP client > > application. > > [>] > > > > I think it boils down to implementation. For instance they could > > have a kernel network driver that sits just above the network > > card, but > > below ip, that snifs dhcp traffic ( well known port). This > > could be wrapped > > in a com object at the application layer that can then acts > > as provider of > > dhcp traffic/signals for other objects, get address object, > > renew object, > > reconfigure ..... In that case a single port makes sense. > > > > nick > > > > > From owner-dhcp-v4@bucknell.edu Wed Mar 21 14:53:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10228 for ; Wed, 21 Mar 2001 14:53:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LJq8e22992; Wed, 21 Mar 2001 14:52:08 -0500 (EST) 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 f2LJpwe19456 for ; Wed, 21 Mar 2001 14:51:58 -0500 (EST) Received: from grosse.bisbee.fugue.com ([206.112.111.82]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2J7WXE03677; Sun, 18 Mar 2001 23:32:33 -0800 (PST) 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 f2LJpbf00368; Wed, 21 Mar 2001 13:51:37 -0600 (CST) Message-Id: <200103211951.f2LJpbf00368@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt In-Reply-To: Message from "Kostur, Andre" of "Wed, 21 Mar 2001 11:46:34 PST." <716D440F8C29D311991100A0C92048740106A578@GIDGET.INCOGNITO.COM> Date: Wed, 21 Mar 2001 13:51:37 -0600 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Couldn't such software emit a DHCPINFORM packet to the DHCP server to get > the set of options back, and parse out the options of interest to the > application? Right, in fact various Win9x applications, most notably Internet Explorer, currently do this. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Mar 21 15:34:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12607 for ; Wed, 21 Mar 2001 15:34:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2LKTAe08266; Wed, 21 Mar 2001 15:29:10 -0500 (EST) Received: from bo1-mwunderlich.ddns.bos.questra.com (vsi-hide.vsi-hq.com [207.231.131.246]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2LKSxe05186 for ; Wed, 21 Mar 2001 15:28:59 -0500 (EST) Received: from wunderware.com ([127.0.0.1]) by bo1-mwunderlich.ddns.bos.questra.com with Microsoft SMTPSVC(5.0.2172.1); Wed, 21 Mar 2001 15:28:36 -0500 Message-ID: <3AB90EF1.F6AE9AA8@wunderware.com> Date: Wed, 21 Mar 2001 15:28:33 -0500 From: Mike Wunderlich X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: DHCP Relay Agents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2001 20:28:36.0028 (UTC) FILETIME=[816D37C0:01C0B245] Reply-To: mike@wunderware.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, Hopefully this is the correct forum for this question. Does anyone have either a) a list of or b) a router they they know or have used that supports DHCP Relay or Bootp forwarding? If so, I'd really appreciate seeing it. Any advice on these products is welcome. My key factor is (of course) price. I don't need much in the way of features but am looking for: -Some manner of remote admin -DHCP/Bootp relaying -Needs to hook RJ-45 on the Lan to RJ-45 on the WAN -Low price That's about it. So far I've found the Nortel 100-s does this rather well for my needs (so says Nortel) but I'm looking to find more options and shop around a bit more before making a decision. Thanks! -Mike From owner-dhcp-v4@bucknell.edu Wed Mar 21 21:36:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03314 for ; Wed, 21 Mar 2001 21:36:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2M2TSe02203; Wed, 21 Mar 2001 21:29:28 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2M2THe04293 for ; Wed, 21 Mar 2001 21:29:17 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA16612; Wed, 21 Mar 2001 21:29:10 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id VAA26955; Wed, 21 Mar 2001 21:29:09 -0500 (EST) Message-ID: <3AB98EA2.57C4156B@cs.columbia.edu> Date: Wed, 21 Mar 2001 21:33:22 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: DHCP for SIP proxy configuration - status update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: hgs@cs.columbia.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit The DHCP option for locating SIP outbound proxy servers was discussed at the first DHCP WG meeting. A number of suggestions were made, including use of a 'marker byte' to indicate the type of address that follows (RFC 1035, host name string, dotted quad). Investigation after the meeting confirmed that recent versions of ISC's dhcpd can indeed support such a structured field for 'unknown' options (i.e., options that have not yet been standardized). However, Windows 2000/NT cannot. Like many older servers (e.g., the Sun DHCP server), it only allows single atomic data types (string, flag, hex-digit string) for unknown options. Thus, based on this issue and in the interest of making forward progress and given the trade-offs involved (flag bytes allow for additional error possibilities if flag byte and content disagree), I believe general consensus was reached to retain the current mechanism and make sure the draft explains that - it should be a FQDN, no dot at end - implementations need to be diligent about recognizing dotted quads This draft has been bouncing around between the two working groups for a while, so I appreciate quick comments if somebody disagrees strongly AND has a viable alternative proposal. Thanks. Henning From owner-dhcp-v6@bucknell.edu Thu Mar 22 01:32:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18224; Thu, 22 Mar 2001 01:32:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2M6TLe32161; Thu, 22 Mar 2001 01:29:21 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2M6T7e32093 for ; Thu, 22 Mar 2001 01:29:07 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2M6T5D06711 for ; Thu, 22 Mar 2001 00:29:06 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2M6T5P19152 for ; Thu, 22 Mar 2001 00:29:05 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 22 00:29:05 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Mar 2001 00:30:55 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694F9557@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu Subject: Allowing unicasts from client to server Date: Thu, 22 Mar 2001 00:30:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B299.A5438560" 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 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_001_01C0B299.A5438560 Content-Type: text/plain; charset="iso-8859-1" Ralph: Regarding the issue of allowing clients to unicast to the server, when one really looks into it, I think there are few instances where this will be of value. We need to document these assuming we want to go forward with it. The cases I could see are: - Renew - Release - Decline - Request (in response to a reconfigure? or if more addresses are desired) In each of the above cases the client MUST have an address of sufficient scope to communicate with the server (assuming the client is allowed to unicast to an off-link server). For other cases: - Rebind *MUST* be multicast. - Confirm I think also *MUST* be multicast. But we probably have a difference of opinion exactly how this will operate and whether other servers (without binding information) may be respond. Regardless, it is really much like Rebind and thus I think it needs to be multicast. Some cases are also tricky since the client might not have an address of sufficient scope. OR, are we only allowing this if the server is on-link (hence, link-local can be used). Assuming the option is desired and we're allowing unicast to off-link servers, how about we also allow the server to specify the IPv6 address to which the client should send the response. This would be an OPTIONAL parameter depending on whether the server-address in the reply is the correct one or not. (If optional parameters in options are desired, I guess we could have another option to specify the unicast server address). So, the option might have the following "parameters": 2-byte option code 2-byte option length (which is either 1 or 17) 1-byte flag (this is 0 if the client must multicast, 1 otherwise; remaining bits reserved?) 16-byte OPTIONAL server's ip-address Finally, if the server says that a client is allowed to unicast, we should say this option is advisor and the client *MAY* (or perhaps *SHOULD*) to it but we should not say that it *MUST* do this. - Bernie Volz Ericsson ------_=_NextPart_001_01C0B299.A5438560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Allowing unicasts from client to server

Ralph:

Regarding the issue of allowing = clients to unicast to the server, when one
really looks into it, I think = there are few instances where this will be of
value. We need to document = these assuming we want to go forward with it. The
cases I could see are:
- Renew
- Release
- Decline
- Request (in response to a = reconfigure? or if more addresses are desired)

In each of the above cases the = client MUST have an address of sufficient
scope to communicate with the = server (assuming the client is allowed to
unicast to an off-link server). = For other cases:

- Rebind *MUST* be = multicast.
- Confirm I think also *MUST* = be multicast. But we probably have a difference
of opinion exactly how this = will operate and whether other servers (without
binding information) may be = respond. Regardless, it is really much like Rebind
and thus I think it needs to be = multicast.

Some cases are also tricky since = the client might not have an address of
sufficient scope. OR, are we = only allowing this if the server is on-link
(hence, link-local can be = used).

Assuming the option is desired = and we're allowing unicast to off-link
servers, how about we also = allow the server to specify the IPv6 address
to which the client should send = the response. This would be an OPTIONAL
parameter depending on whether = the server-address in the reply is the
correct one or not. (If = optional parameters in options are desired, I
guess we could have another = option to specify the unicast server address).

So, the option might have the = following "parameters":
        2-byte option code
        2-byte option length (which is either 1 or = 17)
        1-byte flag (this is 0 if the client must = multicast, 1
          otherwise; remaining bits reserved?)
        16-byte OPTIONAL server's ip-address

Finally, if the server says that = a client is allowed to unicast, we should
say this option is advisor and = the client *MAY* (or perhaps *SHOULD*) to
it but we should not say that = it *MUST* do this.

- Bernie Volz
  Ericsson

------_=_NextPart_001_01C0B299.A5438560-- From owner-dhcp-v6@bucknell.edu Thu Mar 22 01:32:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18290; Thu, 22 Mar 2001 01:32:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2M6UDe05252; Thu, 22 Mar 2001 01:30:13 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2M6Tae29768 for ; Thu, 22 Mar 2001 01:29:36 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2M6TZD06793 for ; Thu, 22 Mar 2001 00:29:35 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2M6TZP19188 for ; Thu, 22 Mar 2001 00:29:35 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 22 00:29:34 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Mar 2001 00:31:25 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694F9561@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DUID privacy issues Date: Thu, 22 Mar 2001 00:31:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B299.B62878E0" 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 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_001_01C0B299.B62878E0 Content-Type: text/plain; charset="iso-8859-1" My answer is "NO". This is really no worse than snooping the IPv6 packets that go across the wire - you can pick-up the client's link-local address which is probably just as meaningful as the DUID. We *MAY* want to point out in the draft, that the DUID is: - For DHCP's use ONLY. Other applications needing a unique identifier SHOULD NOT use this identifier. (I'm relunctant to say MUST NOT because you never know!) - The DUID leaks information about a client (probably more so than the EUI-64 identifier) and therefore must be stored or communicated with care especially when crossing adminstrative domains. - As DHCP is generally used in a single administrative domain, the DUID is unlikely to be seen outside of that domain (except of course if the client connnects to other domains). - In those environments where security of the DUID is an issue (especially in configurations where DHCP traffic or data might cross administrative domains), the data should be secured using IPsec or some other means. This could be done, for example, by using IPsec encryption between the Relay and the Server. On a related note, I do think we SHOULD use a variable length field for the DUID. One important reason is that if a unique identifier is eventually avialable (some brief mention of work in this area was made at the WG session), it sure would be nice to transition to it. If the DUID is fixed length, this may not be possible unless the unique identifier is the same length or shorter. We SHOULD specify a maximum allowed length. (Say 32 bytes?? - this would not include the 1 or 2 byte DUID type field to allow us to specify new DUID formats.) - Bernie Volz -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, March 21, 2001 11:38 AM To: DHCPv6 discussion list Subject: DUID privacy issues Jim brought up the issue that DUIDs could be snooped on the local network and used to violate the privacy of the owner of the DUID. I'd like to solve this, but the problem is that the DUID needs to be fixed, not variable. We don't have a shared secret on the server. I don't really see any way to obscure the DUID and allow it to continue to function. Does anybody have any suggestions? If the answer is no, I think we should just explicitly say "we aren't solving this problem." We *can* insist that the DUID be obscured if it is published - I just don't see how to obscure it on the wire. _MelloN_ ------_=_NextPart_001_01C0B299.B62878E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DUID privacy issues

My answer is "NO".

This is really no worse than snooping the IPv6 = packets that go across the wire - you can pick-up the client's = link-local address which is probably just as meaningful as the = DUID.

We *MAY* want to point out in the draft, that the = DUID is:
- For DHCP's use ONLY. Other applications needing a = unique identifier SHOULD NOT use this identifier. (I'm relunctant to = say MUST NOT because you never know!)

- The DUID leaks information about a client (probably = more so than the EUI-64 identifier) and therefore must be stored or = communicated with care especially when crossing adminstrative = domains.

- As DHCP is generally used in a single = administrative domain, the DUID is unlikely to be seen outside of that = domain (except of course if the client connnects to other = domains).

- In those environments where security of the DUID is = an issue (especially in configurations where DHCP traffic or data might = cross administrative domains), the data should be secured using IPsec = or some other means. This could be done, for example, by using IPsec = encryption between the Relay and the Server.

On a related note, I do think we SHOULD use a = variable length field for the DUID. One important reason is that if a = unique identifier is eventually avialable (some brief mention of work = in this area was made at the WG session), it sure would be nice to = transition to it. If the DUID is fixed length, this may not be possible = unless the unique identifier is the same length or shorter. We SHOULD = specify a maximum allowed length. (Say 32 bytes?? - this would not = include the 1 or 2 byte DUID type field to allow us to specify new DUID = formats.)

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, March 21, 2001 11:38 AM
To: DHCPv6 discussion list
Subject: DUID privacy issues



Jim brought up the issue that DUIDs could be snooped = on the local
network and used to violate the privacy of the owner = of the DUID.
I'd like to solve this, but the problem is that the = DUID needs to be
fixed, not variable.   We don't have a = shared secret on the server.
I don't really see any way to obscure the DUID and = allow it to
continue to function.

Does anybody have any suggestions?   If the = answer is no, I think we
should just explicitly say "we aren't solving = this problem."   We
*can* insist that the DUID be obscured if it is = published - I just
don't see how to obscure it on the wire.

        =         =                _MelloN_

------_=_NextPart_001_01C0B299.B62878E0-- From owner-dhcp-v4@bucknell.edu Thu Mar 22 07:39:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10107 for ; Thu, 22 Mar 2001 07:39:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2MCXie19581; Thu, 22 Mar 2001 07:33:44 -0500 (EST) Received: from bacon.intranet-solutions.com (bacon.intranet-solutions.com [195.173.37.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2MCXZe21089 for ; Thu, 22 Mar 2001 07:33:36 -0500 (EST) Received: from ham.INTRANET-SOLUTIONS.COM ([194.159.157.193]) by bacon.intranet-solutions.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with ESMTP id AAA250; Thu, 22 Mar 2001 11:31:15 +0000 Received: from istechl2 (IS-TECH-L2.INTRANET-SOLUTIONS.COM [194.159.157.174]) by ham.INTRANET-SOLUTIONS.COM (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-55555U100L100S0) with SMTP id AAA191; Thu, 22 Mar 2001 11:32:28 +0000 From: "Paul Roberts" To: DHCPv4 discussion list Subject: RE: Settings configured with DHCP Date: Thu, 22 Mar 2001 11:34:20 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <985190771.3ab8d1739a1a0@paris-hme1> Reply-To: paul.roberts@intranet-solutions.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN X-MIME-Autoconverted: from 8bit to quoted-printable by mail.bucknell.edu id f2MCXie19581 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA10107 I think Microsoft use DHCP option code 252 to do this. Regards, Paul Roberts Professional Services +---------------------------------------------+ | Paul Roberts, Intranet Solutions, | | Tel: +44 1252 849008 Fax: +44 1252 849097 | | E-mail: paul.roberts@intranet-solutions.com | | WWW: http://www.intranet-solutions.com | +---------------------------------------------+ > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Joao Santos > Sent: 21 March 2001 16:06 > To: DHCPv4 discussion list > Subject: Settings configured with DHCP > > > Hello! > > When you use a DHCP server, a client is informed of > what IP address it can use, and who is the DNS server, > right? > > Is there any way to also automatically configure a > proxy server? When a client connects to the DHCP > server it would also receive the information of what > proxy server to use... is this even possible? > > Regards, > Joao Santos > > ------------------------------------------------- > Email Enviado utilizando o serviço MegaMail > From owner-dhcp-v6@bucknell.edu Thu Mar 22 09:01:42 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11344; Thu, 22 Mar 2001 09:01:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2MDx1e15154; Thu, 22 Mar 2001 08:59:01 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2MDwke05762 for ; Thu, 22 Mar 2001 08:58:46 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2MDwIg03791 for ; Thu, 22 Mar 2001 07:58:38 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 22 Mar 2001 07:58:14 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 22 Mar 2001 07:58:14 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: Allowing unicasts from client to server Date: Thu, 22 Mar 2001 07:58:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B2D8.22C43D20" 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 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_001_01C0B2D8.22C43D20 Content-Type: text/plain; charset="iso-8859-1" bernie, the other reason is performance. it could cost more to hop thru the relay than directly to a router that forwards that prefix in its fast path off the lan in IPv6. /jim -----Original Message----- From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday,March 22,2001 1:31 AM To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu Subject: Allowing unicasts from client to server Ralph: Regarding the issue of allowing clients to unicast to the server, when one really looks into it, I think there are few instances where this will be of value. We need to document these assuming we want to go forward with it. The cases I could see are: - Renew - Release - Decline - Request (in response to a reconfigure? or if more addresses are desired) In each of the above cases the client MUST have an address of sufficient scope to communicate with the server (assuming the client is allowed to unicast to an off-link server). For other cases: - Rebind *MUST* be multicast. - Confirm I think also *MUST* be multicast. But we probably have a difference of opinion exactly how this will operate and whether other servers (without binding information) may be respond. Regardless, it is really much like Rebind and thus I think it needs to be multicast. Some cases are also tricky since the client might not have an address of sufficient scope. OR, are we only allowing this if the server is on-link (hence, link-local can be used). Assuming the option is desired and we're allowing unicast to off-link servers, how about we also allow the server to specify the IPv6 address to which the client should send the response. This would be an OPTIONAL parameter depending on whether the server-address in the reply is the correct one or not. (If optional parameters in options are desired, I guess we could have another option to specify the unicast server address). So, the option might have the following "parameters": 2-byte option code 2-byte option length (which is either 1 or 17) 1-byte flag (this is 0 if the client must multicast, 1 otherwise; remaining bits reserved?) 16-byte OPTIONAL server's ip-address Finally, if the server says that a client is allowed to unicast, we should say this option is advisor and the client *MAY* (or perhaps *SHOULD*) to it but we should not say that it *MUST* do this. - Bernie Volz Ericsson ------_=_NextPart_001_01C0B2D8.22C43D20 Content-Type: text/html; charset="iso-8859-1" Allowing unicasts from client to server
bernie,
 
the other reason is performance.  it could cost more to hop thru the relay than directly to a router that forwards that prefix in its fast path off the lan in IPv6.
 
/jim
-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday,March 22,2001 1:31 AM
To: DHCPv6 discussion list
Cc: dhcp-v6@bucknell.edu
Subject: Allowing unicasts from client to server

Ralph:

Regarding the issue of allowing clients to unicast to the server, when one
really looks into it, I think there are few instances where this will be of
value. We need to document these assuming we want to go forward with it. The
cases I could see are:
- Renew
- Release
- Decline
- Request (in response to a reconfigure? or if more addresses are desired)

In each of the above cases the client MUST have an address of sufficient
scope to communicate with the server (assuming the client is allowed to
unicast to an off-link server). For other cases:

- Rebind *MUST* be multicast.
- Confirm I think also *MUST* be multicast. But we probably have a difference
of opinion exactly how this will operate and whether other servers (without
binding information) may be respond. Regardless, it is really much like Rebind
and thus I think it needs to be multicast.

Some cases are also tricky since the client might not have an address of
sufficient scope. OR, are we only allowing this if the server is on-link
(hence, link-local can be used).

Assuming the option is desired and we're allowing unicast to off-link
servers, how about we also allow the server to specify the IPv6 address
to which the client should send the response. This would be an OPTIONAL
parameter depending on whether the server-address in the reply is the
correct one or not. (If optional parameters in options are desired, I
guess we could have another option to specify the unicast server address).

So, the option might have the following "parameters":
        2-byte option code
        2-byte option length (which is either 1 or 17)
        1-byte flag (this is 0 if the client must multicast, 1
          otherwise; remaining bits reserved?)
        16-byte OPTIONAL server's ip-address

Finally, if the server says that a client is allowed to unicast, we should
say this option is advisor and the client *MAY* (or perhaps *SHOULD*) to
it but we should not say that it *MUST* do this.

- Bernie Volz
  Ericsson

------_=_NextPart_001_01C0B2D8.22C43D20-- From owner-dhcp-v6@bucknell.edu Mon Mar 26 03:35:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08030; Mon, 26 Mar 2001 03:35:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2Q8WFe30101; Mon, 26 Mar 2001 03:32:16 -0500 (EST) Received: from givenchy (IDENT:postfix@mailhost.6wind.com [212.234.238.114]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2Q8W0e20613 for ; Mon, 26 Mar 2001 03:32:00 -0500 (EST) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id EA08A8FD for ; Mon, 26 Mar 2001 11:37:26 +0200 (CEST) Received: from 6wind.com (faberge [10.16.0.79]) by intranet.6wind.com (Postfix) with ESMTP id 9CC9AB478 for ; Mon, 26 Mar 2001 02:32:22 -0600 (CST) Message-ID: <3ABF0CBB.A11C8137@6wind.com> Date: Mon, 26 Mar 2001 11:32:43 +0200 From: jmg X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: option IA Content-Type: multipart/alternative; boundary="------------1708A6CA179B28081698D5F8" 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 --------------1708A6CA179B28081698D5F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, - Just to make a little thing clearer : in draft-v18, section 16.2, should i read option-len Variable; equal to 18 + num-addrs*26 (instead of 25) ? - About the definition of client-binding : A binding is indexed by the tuple , where the 'prefix' is a prefix assigned to the link to which the client is attached and 'DUID' is the DUID from the IA in the binding. Does it mean all addresses in an IA have the same prefix ? Is this prefix based on an eventually relay-address/prefix length received in a forward message ? thanks you all for your help --------------1708A6CA179B28081698D5F8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hello,
- Just to make a little thing clearer : in draft-v18, section 16.2, should i read
option-len Variable; equal to 18 + num-addrs*26 (instead of 25) ?
- About the definition of client-binding :
    A binding is indexed by the tuple <prefix, DUID>, where the 'prefix' is a prefix assigned to the link to which the client is attached and 'DUID' is the DUID from the IA in the binding.
Does it mean all addresses in an IA have the same prefix ?
Is this prefix based on an eventually relay-address/prefix length received in a forward message ?

thanks you all for your help
 
  --------------1708A6CA179B28081698D5F8-- From owner-dhcp-v6@bucknell.edu Mon Mar 26 10:21:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07640; Mon, 26 Mar 2001 10:21:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2QEele16490; Mon, 26 Mar 2001 09:40:47 -0500 (EST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2QEege12807 for ; Mon, 26 Mar 2001 09:40:43 -0500 (EST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f2QEePd35040 for ; Mon, 26 Mar 2001 15:40:25 +0100 Received: from rennes.enst-bretagne.fr (jugon.rennes.enst-bretagne.fr [193.52.74.50]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA14620 for ; Mon, 26 Mar 2001 16:40:24 +0200 (MET DST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3ABF54D7.F65A8426@rennes.enst-bretagne.fr> Date: Mon, 26 Mar 2001 16:40:23 +0200 From: Jerome MARCHAND Organization: ENST Bretagne X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Request messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: jmarchan@rennes.enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, In sub-section 13.3.1 of draft 18, Why are the REQUEST messages sent to multicast address ( All DHCP Agents ), given that the "server-address" field contains the address of the DHCP server we'd like to talk to ? Why don't we send it directly to that server unicast address ? Thank and regards. From owner-dhcp-v6@bucknell.edu Mon Mar 26 11:34:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11470; Mon, 26 Mar 2001 11:34:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2QGUBe20615; Mon, 26 Mar 2001 11:30:12 -0500 (EST) 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 f2QGTqe20728 for ; Mon, 26 Mar 2001 11:29:53 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-151.cisco.com [161.44.149.151]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA16901; Mon, 26 Mar 2001 11:29:34 -0500 (EST) Message-Id: <4.3.2.7.2.20010326111401.0355b5b8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Mar 2001 11:29:17 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Request messages Cc: DHCPv6 discussion list In-Reply-To: <3ABF54D7.F65A8426@rennes.enst-bretagne.fr> 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 Prior to the -18 draft, we made a design decision that all messages would be forwarded through relay agents so those relay agents can attach relay agent options to all messages. Experience with DHCPv4 has shown that there are situations in which its useful to get those options on all messages. We did discuss a proposal in Minneapolis for an optimization which would allow clients to unicast to servers when possible. Turns out only a few messages can be unicast - we'll add text to the next rev of the draft specifying when unicast can be used and how the server can control use of unicast. - Ralph Droms At 04:40 PM 3/26/2001 +0200, Jerome MARCHAND wrote: >In sub-section 13.3.1 of draft 18, >Why are the REQUEST messages sent to >multicast address ( All DHCP Agents ), >given that the "server-address" field >contains the address of the DHCP server >we'd like to talk to ? >Why don't we send it directly to that >server unicast address ? From owner-dhcp-v6@bucknell.edu Mon Mar 26 22:21:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26922; Mon, 26 Mar 2001 22:21:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2R2Ywe30823; Mon, 26 Mar 2001 21:34:58 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2R2Yte07211 for ; Mon, 26 Mar 2001 21:34:55 -0500 (EST) Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id MAA274924 for ; Tue, 27 Mar 2001 12:25:00 +1000 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA88450 for ; Tue, 27 Mar 2001 12:33:52 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A1C.000E139E ; Tue, 27 Mar 2001 12:33:45 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Tue, 27 Mar 2001 07:56:25 +0530 Subject: Re: Request messages Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Please respond to dhcp-v6@bucknell.edu To: DHCPv6 discussion list cc: (bcc: Suresh Kodati/India/IBM) Subject: Request messages Hi, In sub-section 13.3.1 of draft 18, Why are the REQUEST messages sent to multicast address ( All DHCP Agents ), given that the "server-address" field contains the address of the DHCP server we'd like to talk to ? Why don't we send it directly to that server unicast address ? Thank and regards. Hi if the client do not have sufficient scope to reach the server, the relays configured for all dhcp agents mulitcast address forwards the REQUEST message to the corresponding server unicast address. Suresh Kodati From owner-dhcp-v6@bucknell.edu Tue Mar 27 05:22:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16334; Tue, 27 Mar 2001 05:22:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2RAIae31856; Tue, 27 Mar 2001 05:18:36 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2RAILe26891 for ; Tue, 27 Mar 2001 05:18:22 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2RAIKm28890 for ; Tue, 27 Mar 2001 04:18:20 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2RAIKW05409 for ; Tue, 27 Mar 2001 04:18:20 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Mar 27 04:18:19 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 04:18:19 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694F9671@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: option IA Date: Tue, 27 Mar 2001 04:18:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B6A7.3EBA8A20" 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 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_001_01C0B6A7.3EBA8A20 Content-Type: text/plain; charset="iso-8859-1" This has changed. The prefix is not likely to be needed. The IA option is likely to contain something different from the DUID (perhaps just an IA id). The DUID is (hopefully) going to appear elsewhere in the message and truely be a client level identifier. An IA id or something similar will likely be used to specify the address binding for the DUID. We'll have to wait for the -19 draft to find out exactly how this will be dealt with unless Ralph posts something sooner. - Bernie -----Original Message----- From: jmg [mailto:jean-mickael.guerin@6wind.com] Sent: Monday, March 26, 2001 4:33 AM To: DHCPv6 discussion list Subject: option IA hello, - Just to make a little thing clearer : in draft-v18, section 16.2, should i read option-len Variable; equal to 18 + num-addrs*26 (instead of 25) ? - About the definition of client-binding : A binding is indexed by the tuple , where the 'prefix' is a prefix assigned to the link to which the client is attached and 'DUID' is the DUID from the IA in the binding. Does it mean all addresses in an IA have the same prefix ? Is this prefix based on an eventually relay-address/prefix length received in a forward message ? thanks you all for your help ------_=_NextPart_001_01C0B6A7.3EBA8A20 Content-Type: text/html; charset="iso-8859-1"

This has changed. The prefix is not likely to be needed.
 
The IA option is likely to contain something different from the DUID (perhaps just an IA id). The DUID is (hopefully) going to appear elsewhere in the message and truely be a client level identifier. An IA id or something similar will likely be used to specify the address binding for the DUID.
 
We'll have to wait for the -19 draft to find out exactly how this will be dealt with unless Ralph posts something sooner.
 
- Bernie
-----Original Message-----
From: jmg [mailto:jean-mickael.guerin@6wind.com]
Sent: Monday, March 26, 2001 4:33 AM
To: DHCPv6 discussion list
Subject: option IA

hello,
- Just to make a little thing clearer : in draft-v18, section 16.2, should i read
option-len Variable; equal to 18 + num-addrs*26 (instead of 25) ?
- About the definition of client-binding :
    A binding is indexed by the tuple <prefix, DUID>, where the 'prefix' is a prefix assigned to the link to which the client is attached and 'DUID' is the DUID from the IA in the binding.
Does it mean all addresses in an IA have the same prefix ?
Is this prefix based on an eventually relay-address/prefix length received in a forward message ?

thanks you all for your help
 
 

------_=_NextPart_001_01C0B6A7.3EBA8A20-- From owner-dhcp-v4@bucknell.edu Tue Mar 27 11:53:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22694 for ; Tue, 27 Mar 2001 11:53:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2RGlbe13957; Tue, 27 Mar 2001 11:47:38 -0500 (EST) Received: from server-23.tower-4.starlabs.net (mail.london-1.starlabs.net [212.125.75.12]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2RGlMe17776 for ; Tue, 27 Mar 2001 11:47:22 -0500 (EST) X-VirusChecked: Checked Received: (qmail 32624 invoked from network); 27 Mar 2001 16:46:04 -0000 Received: from gate-isdn.tpd.co.uk (194.152.89.193) by server-23.tower-4.starlabs.net with SMTP; 27 Mar 2001 16:46:04 -0000 Received: (qmail 10045 invoked by uid 505); 27 Mar 2001 16:52:10 -0000 Received: from david.stringer@theinagency.co.uk by gate-isdn.tpd.co.uk with scan4virus-0.19 (uvscan: v4.0.35/v4078. . Clean. Processed in 0.313855 secs); 27/03/2001 17:52:09 Received: from serv1.theinagency.co.uk (HELO davids) (194.152.89.230) by gate-isdn.tpd.co.uk with SMTP; 27 Mar 2001 16:52:09 -0000 From: "David Stringer" To: DHCPv4 discussion list Subject: moving DHCP servers Date: Tue, 27 Mar 2001 17:48:13 +0100 Message-ID: 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Reply-To: david.stringer@theinagency.co.uk Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, I am trying to migrate my dhcp server to another machine but the clients seem to 'stick' to the same dhcp server, even though I have tried several variations of renewing the liscenses. I am obviously missing a key point but cannot find how to get around the problem in the FAQ or other docs Please, a quick pointer in the right direction would be lovely Cheers.. Dave _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. For further information visit http://www.messagelabs.com/stats.asp From owner-dhcp-v4@bucknell.edu Tue Mar 27 14:23:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26959 for ; Tue, 27 Mar 2001 14:23:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2RJ95e23596; Tue, 27 Mar 2001 14:09:05 -0500 (EST) Received: from firewall.ma.virata.com (agranat.com [198.113.147.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2RJ93e31844 for ; Tue, 27 Mar 2001 14:09:03 -0500 (EST) Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id OAA32201 for ; Tue, 27 Mar 2001 14:08:48 -0500 Received: from localhost.localdomain (IDENT:root@dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.9.3/8.9.3) with ESMTP id OAA07373 for ; Tue, 27 Mar 2001 14:08:47 -0500 Received: (from worley@localhost) by localhost.localdomain (8.11.0/8.8.7) id f2RJ8lo18019; Tue, 27 Mar 2001 14:08:47 -0500 Date: Tue, 27 Mar 2001 14:08:47 -0500 Message-Id: <200103271908.f2RJ8lo18019@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: worley set sender to dworley@virata.com using -f From: worley@agranat.com To: DHCPv4 discussion list In-reply-to: Subject: Re: moving DHCP servers References: 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: "David Stringer" I am trying to migrate my dhcp server to another machine but the clients seem to 'stick' to the same dhcp server, even though I have tried several variations of renewing the liscenses. The clients return to the original server to get their leases renewed (since that can be done without broadcasts). I *think* that that is specified behavior, though I'm not sure. Only after failing to get a renewal from the original server will the client broadcast to find a new server. It seems like the solution is to turn off the old server to force the clients to find the new one. Dale -- Dale R. WORLEY Project Manager - UPnP Virata Corp. Applications Infrastructure http://emweb.com From owner-dhcp-v4@bucknell.edu Thu Mar 29 11:21:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21763 for ; Thu, 29 Mar 2001 11:21:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TG5Ce11108; Thu, 29 Mar 2001 11:05:12 -0500 (EST) Received: from server-9.tower-4.starlabs.net (mail.london-1.starlabs.net [212.125.75.12]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TG2me14008 for ; Thu, 29 Mar 2001 11:02:50 -0500 (EST) X-VirusChecked: Checked Received: (qmail 16662 invoked from network); 29 Mar 2001 16:01:42 -0000 Received: from gate-isdn.tpd.co.uk (194.152.89.193) by server-9.tower-4.starlabs.net with SMTP; 29 Mar 2001 16:01:42 -0000 Received: (qmail 2612 invoked by uid 505); 29 Mar 2001 16:07:38 -0000 Received: from david.stringer@theinagency.co.uk by gate-isdn.tpd.co.uk with scan4virus-0.19 (uvscan: v4.0.35/v4078. . Clean. Processed in 0.313939 secs); 29/03/2001 17:07:38 Received: from serv1.theinagency.co.uk (HELO davids) (194.152.89.230) by gate-isdn.tpd.co.uk with SMTP; 29 Mar 2001 16:07:37 -0000 From: "David Stringer" To: DHCPv4 discussion list Subject: moving servers Date: Thu, 29 Mar 2001 17:03:42 +0100 Message-ID: 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Reply-To: david.stringer@theinagency.co.uk Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, Are there any tools for querying DHCP servers to ensure they are working correctly as I still cant persuade any client machines to move to the new DHCP server. When they cant find the old dhcp server the client machines [win NT/2K] just give up and make up their own IP address, which is not helpful for useful networking. Cheers Dave _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. For further information visit http://www.messagelabs.com/stats.asp From owner-dhcp-v4@bucknell.edu Thu Mar 29 14:43:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06401 for ; Thu, 29 Mar 2001 14:43:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TJQ6e23058; Thu, 29 Mar 2001 14:26:06 -0500 (EST) 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 f2TJOWe07635 for ; Thu, 29 Mar 2001 14:24:34 -0500 (EST) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Mar 2001 11:29:41 -0800 Message-ID: <716D440F8C29D311991100A0C9204874B574B0@GIDGET.INCOGNITO.COM> From: "Cosmo, Patrick" To: DHCPv4 discussion list Subject: latest LDAP-DHCP schema draft ? Date: Thu, 29 Mar 2001 11:29:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Patrick@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Where can I find the latest LDAP-DHCP schema draft? www.dhcp.org/drafts.html has a DHCP server LDAP schema link to http://www.ietf.org/internet-drafts/draft-ietf-dhc-schema-02.txt. But if you try to go to this link, you get a page not found error. I found a link to drafts-ietf-dhc-schema-04.txt at http://ftp.fh-schmalkalden.de/pub/documents/internet-drafts/draft-ietf-dhc-s chema-04.txt, but going to this link returns an "This Internet-Draft has been deleted. " page. I've tried a number of other sites, but just can't seem to find it. Any help? thanks, Patrick From owner-dhcp-v6@bucknell.edu Thu Mar 29 15:26:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08840; Thu, 29 Mar 2001 15:26:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TKNLe27002; Thu, 29 Mar 2001 15:23:21 -0500 (EST) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2TKN7e30262 for ; Thu, 29 Mar 2001 15:23:08 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3att.ericy.com [138.85.92.10]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f2TKMo822636 for ; Thu, 29 Mar 2001 14:22:50 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2TKMor23988 for ; Thu, 29 Mar 2001 14:22:50 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 29 14:22:45 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Mar 2001 14:22:45 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694F9776@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Cc: aboba@internaut.com, jim.bound@nokia.com, deering@cisco.com, erik.guttman@sun.com, itojun@iijlab.net, hinden@IPRG.NOKIA.COM, jinmei@isl.rdc.toshiba.com, onoe@sm.sony.co.jp, hesham.soliman@ericsson.com, dthaler@microsoft.com Subject: draft-ietf-ipngwg-dns-discovery-00.txt Date: Thu, 29 Mar 2001 14:22:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B88D.F2A9D5D0" 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 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_001_01C0B88D.F2A9D5D0 Content-Type: text/plain; charset="iso-8859-1" Folks: Regarding the discussion at the DHC WG at the Minneapolis IETF on Wednesday (on DHCPv6) on draft-ietf-ipngwg-dns-discovery-00.txt (and the design team), why was the idea of using a DHCP server eliminated? Seems to me like that's the simplest way? I agree it isn't possible today because we haven't finished the DHCPv6 work. However, you're going to do this requires some code to implement. So, why not just develop mini-DHCPv6 servers. A DNS server system may include a mini-DHCPv6 server which responds with only configuration parameters. A Router, if not configured as a DHCP relay, may also have a mini-DHCPv6 server. Rules for the mini-DHCPv6 server: - Preference value must be 0 (minimum preference value). - Must *NOT* assign any addresses. Can only be used to configure parameters such as domain name, domain name search list, DNS server addresses, etc. These mini-DHCPv6 servers shouldn't be that difficult to implement. And, it might also be possible to use a short-cut in just sending SOLICIT and ADVERTISE messages (the SOLICIT can request the configuration parameters desired). This should also force more rapid deployment of DHCPv6 in clients and servers, rather than having (yet) another means to provide configuration parameters. And, it would more clearly convey that DHCP is not just for addresses (which I think is still a common perception today). I also feel that just focusing on DNS parameters is short sighted and likely to lead to the need for more protocols in the future should other parameters need configuration in a 'stateless' environment. And it doesn't make sense to associate these other configuration parameters with DNS - but it does to do so with DHCP. Regarding the criteria, here's my response to the items: Scalability - This is scaleable to large number of devices, since DHCPv6 must be and DHCPv4 has shown that it is. Security - The same mechanism as is being (soon will be) proposed for DHCPv6 can be used. We're hoping to essentially use the DHCPv4 authentication framework. If that security isn't good enough, perhaps additional methods need to be looked at (this would also benefit DHCP!). Time to Deploy - It will take a little time since we need to clean up the DHCPv6 specification. This should not take long (and likely less time than developing a new mechanism and working out the issues with that). Routers and servers will need to have new software deployed (as well as clients, but hopefully DHCPv6 will become standard on them anyway). We could always define DHCPv6 operation for non-addresses now and work out the address issues in parallel. Business Motivation - This is exactly why DHCPv6 would be a better approach. It will benefit DHCPv6 as well. Standardization - Yes and no. We just need to finish the DHCPv6 work (or at least a subset of it). There's also already a working group for this work. Fate Sharing - Don't believe so. Convergence Time - Same as DHCP. Scenarios - Isolated link with a DNS server but no routers: Yes, if the mini-DHCPv6 server is placed on the network (probably best on the DNS server system). Scenarios - Site with routers, but no multicast routing enabled: Yes, either mini-DHCPv6 server is run on router (instead of relay) and configured with parameters or a DHCPv6 relay is running. Scenarios - Hosts connected over an NBMA link: This may be a problem but then DHCPv6 would suffer from the same problem. - Bernie Volz Ericsson ------_=_NextPart_001_01C0B88D.F2A9D5D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-ipngwg-dns-discovery-00.txt

Folks:

Regarding the discussion at the DHC WG at the Minneapolis IETF on = Wednesday (on DHCPv6) on draft-ietf-ipngwg-dns-discovery-00.txt (and = the design team), why was the idea of using a DHCP server eliminated? = Seems to me like that's the simplest way? I agree it isn't possible = today because we haven't finished the DHCPv6 work.

However, you're going to do this = requires some code to implement. So, why not just develop mini-DHCPv6 = servers. A DNS server system may include a mini-DHCPv6 server which = responds with only configuration parameters. A Router, if not = configured as a DHCP relay, may also have a mini-DHCPv6 = server.

Rules for the mini-DHCPv6 = server:
- Preference value must be 0 = (minimum preference value).
- Must *NOT* assign any = addresses. Can only be used to configure parameters such as domain = name, domain name search list, DNS server addresses, etc.

These mini-DHCPv6 servers = shouldn't be that difficult to implement. And, it might also be = possible to use a short-cut in just sending SOLICIT and ADVERTISE = messages (the SOLICIT can request the configuration parameters = desired).

This should also force more = rapid deployment of DHCPv6 in clients and servers, rather than having = (yet) another means to provide configuration parameters. And, it would = more clearly convey that DHCP is not just for addresses (which I think = is still a common perception today).

I also feel that just focusing = on DNS parameters is short sighted and likely to lead to the need for = more protocols in the future should other parameters need configuration = in a 'stateless' environment. And it doesn't make sense to associate = these other configuration parameters with DNS - but it does to do so = with DHCP.

Regarding the criteria, here's = my response to the items:

Scalability - This is scaleable = to large number of devices, since DHCPv6 must be and DHCPv4 has shown = that it is.

Security - The same mechanism as = is being (soon will be) proposed for DHCPv6 can be used. We're hoping = to essentially use the DHCPv4 authentication framework. If that = security isn't good enough, perhaps additional methods need to be = looked at (this would also benefit DHCP!).

Time to Deploy - It will take a = little time since we need to clean up the DHCPv6 specification. This = should not take long (and likely less time than developing a new = mechanism and working out the issues with that). Routers and servers = will need to have new software deployed (as well as clients, but = hopefully DHCPv6 will become standard on them anyway). We could always = define DHCPv6 operation for non-addresses now and work out the address = issues in parallel.

Business Motivation - This is = exactly why DHCPv6 would be a better approach. It will benefit DHCPv6 = as well.

Standardization - Yes and no. We = just need to finish the DHCPv6 work (or at least a subset of it). = There's also already a working group for this work.

Fate Sharing - Don't believe = so.

Convergence Time - Same as = DHCP.

Scenarios - Isolated link with a = DNS server but no routers: Yes, if the mini-DHCPv6 server is placed on = the network (probably best on the DNS server system).

Scenarios - Site with routers, = but no multicast routing enabled: Yes, either mini-DHCPv6 server is run = on router (instead of relay) and configured with parameters or a DHCPv6 = relay is running.

Scenarios - Hosts connected over = an NBMA link: This may be a problem but then DHCPv6 would suffer from = the same problem.

- Bernie Volz
  Ericsson

------_=_NextPart_001_01C0B88D.F2A9D5D0-- From owner-dhcp-v4@bucknell.edu Thu Mar 29 15:28:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08969 for ; Thu, 29 Mar 2001 15:28:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TKNLe05259; Thu, 29 Mar 2001 15:23:21 -0500 (EST) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2TKN6e12770 for ; Thu, 29 Mar 2001 15:23:06 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3att.ericy.com [138.85.92.10]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f2TKMa822577 for ; Thu, 29 Mar 2001 14:22:40 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2TKMar23838 for ; Thu, 29 Mar 2001 14:22:36 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 29 14:22:34 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Mar 2001 14:22:34 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694F9775@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: DHCP Option Tag Exhaustion (1..127) Date: Thu, 29 Mar 2001 14:22:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B88D.F0FA5110" Reply-To: Bernie.Volz@am1.ericsson.se 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_001_01C0B88D.F0FA5110 Content-Type: text/plain; charset="iso-8859-1" Folks: This message is to start (or restart) the discussion (on the WG mailing list) around addressing the likely upcoming exhaustion of the DHCPv4 option space. As specified in RFC 2132: Option codes 128 to 254 (decimal) are reserved for site-specific options. Thus, we only have option codes 1 to 127 available for IETF specified options. Values 0 (pad) and 255 (end) are otherwise used [RFC 2132]. The most obvious solutions I believe are: 1. Expand the range of IETF specified options by reclaiming some range in the 128 to 254 range. 2. Use a new magic cookie value to specify a 16-bit option space. 3. Use one of the remaining unassigned option tags (<128) to encapsulate new 16-bit options (or perhaps simply to extend the option space by another 256 values). If there are other solutions, it would be useful for these to be discussed as well. Here's some initial comments on the solutions listed above proposed: 1. Expand the range of the IETF specified options by reclaiming some space in the 128 to 254 range. This would require collecting information on which values are currently in use (unless that usage is very self contained and easily redeployable to a different value). For example, Microsoft uses several values in their products which would be difficult to change because of the large number of hosts in the market. Perhaps the range from 160 to 223 may be available (that is based on my probably incorrect belief that people would start at one end of the range or the other). The pro for this approach is that it really requires no code changes in clients or servers (other than to implement the new options when they are defined). The con for this approach is we might not learn of all of the options in use and therefore cause a collision with an existing option. 2. Use a new magic cookie to specify a 16-bit option space. This seems fairly straight forward in theory. If the new magic cookie appears in a DHCP (BOOTP) packet, the new client and server simply use the 16-bit option format proposed for DHCPv6 (16-bit tag followed by 16-bit data length following by the data). Options 0 to 255 would retain their same meaning whether in the 8-bit or 16-bit format. One issue is how do the client / relay / server negotiate the use of the new format? Does the client send a Discover with the new magic cookie and if it receives no replies after some number of attempts, fall back to the old magic cookie? Does it send two Discovers (one with new and one with old)? If a relay receives a packet with the new cookie, it won't forward it(?). Thus, this requires that both relays and servers be upgraded in order for the new format to be available to servers behind relays? And, of course this requires fairly substantial code changes in clients, relays, and servers. So, the pro for this approach is rather limited - we achieve our goal. The cons for this approach are rather large: - Major code changes - Relays and servers need to be changed at same time (otherwise changing servers does no good for clients behind a relay) - DHCP traffic is increased with the client sending multiple Discovers (and servers perhaps sending multiple offers) to find out whether a server can support the new format. 3. Encapsulation. We define a new encapsulation option. In its simplest form, this option would encapsulate 16-bit formatted options (formatted like DHCPv6 options). Using Ted Lemon's new concatenation draft (draft-ietf-dhc-concat-*.txt), this encapsulation option could easily be more than 255 bytes in length. In other forms, perhaps we use a 16-bit option code by 8-bit length. Or we us an ASN.1 like number encoding - each byte of the option tag and option length encodes 7-bits of data and one bit specifies whether another byte of tag (or length) follows. The format for the basic option is: Code Len Extended option 1 Extended option 2 +-----+-----+-----+-----+-----+-----+--- ... ---+-----+-----+-----+-----+... | TBD | Len | ETAG1 | ELEN1 | EDATA1... | ETAG2 | ELEN2 |... +-----+-----+-----+-----+-----+-----+--- ... ---+-----+-----+-----+-----+... While any option COULD be encapsulated, existing options (tag < 256) SHOULD NOT be encapsulated (since they do not need to be). A client that supports this technique would advertise that fact to a server by including the tag assigned to the encapsulation option in a Parameter Request List option (55). A client would also include any 16-bit options it wanted by encapsulating an "Extended Parameter Request List" option in an encapsulation option (the client could of course include any additional options as well). This "Extended Parameter Request List" option would be a new option, assigned from the >255 tag list, which is essentially identical to the existing Parameter Request List option except that 16-bit option values are used. Note: The "Extended Parameter Request List" option could be a 8-bit option (which would eliminate the need to encapsulate it). The pros of this approach are that no changes to existing clients and servers are needed (unless they want to support new options >255). We can start assigning new options and clients or servers that want to implement them can. No impact to relays as they pass the options on as before (just data to them). If new relay agent type options are needed, they too could be assigned in the >255 range. The cons of this approach are minimal, when implementing the FIRST >255 option, additional client, server, or relay work is needed. And, I guess to be fair, some bytes are "wasted" in the encapsulation option overhead. But, that's fairly minimal. Of course, my preference is for the Encapsulation technique (3). If there are additional techniques that might have been discussed in the past or that you think of, or you feel that I've misrepresented the techniques, pros, or cons, please comment. - Bernie Volz Ericsson ------_=_NextPart_001_01C0B88D.F0FA5110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DHCP Option Tag Exhaustion (1..127)

Folks:

This message is to start (or = restart) the discussion (on the WG mailing list) around addressing the = likely upcoming exhaustion of the DHCPv4 option space. As specified in = RFC 2132:

        Option codes 128 to 254 (decimal) are reserved for = site-specific options.

Thus, we only have option codes = 1 to 127 available for IETF specified options. Values 0 (pad) and 255 = (end) are otherwise used [RFC 2132].

The most obvious solutions I = believe are:
1. Expand the range of IETF = specified options by reclaiming some range in the 128 to 254 = range.
2. Use a new magic cookie value = to specify a 16-bit option space.
3. Use one of the remaining = unassigned option tags (<128) to encapsulate new 16-bit options (or = perhaps simply to extend the option space by another 256 = values).

If there are other solutions, it = would be useful for these to be discussed as well.

Here's some initial comments on = the solutions listed above proposed:

1. Expand the range of the IETF = specified options by reclaiming some space in the 128 to 254 = range.

This would require collecting = information on which values are currently in use (unless that usage is = very self contained and easily redeployable to a different value). For = example, Microsoft uses several values in their products which would be = difficult to change because of the large number of hosts in the = market.

Perhaps the range from 160 to = 223 may be available (that is based on my probably incorrect belief = that people would start at one end of the range or the = other).

The pro for this approach is = that it really requires no code changes in clients or servers (other = than to implement the new options when they are defined).

The con for this approach is we = might not learn of all of the options in use and therefore cause a = collision with an existing option.

2. Use a new magic cookie to = specify a 16-bit option space.

This seems fairly straight = forward in theory. If the new magic cookie appears in a DHCP (BOOTP) = packet, the new client and server simply use the 16-bit option format = proposed for DHCPv6 (16-bit tag followed by 16-bit data length = following by the data). Options 0 to 255 would retain their same = meaning whether in the 8-bit or 16-bit format.

One issue is how do the client / = relay / server negotiate the use of the new format? Does the client = send a Discover with the new magic cookie and if it receives no replies = after some number of attempts, fall back to the old magic cookie? Does = it send two Discovers (one with new and one with old)? If a relay = receives a packet with the new cookie, it won't forward it(?). Thus, = this requires that both relays and servers be upgraded in order for the = new format to be available to servers behind relays?

And, of course this requires = fairly substantial code changes in clients, relays, and servers.

So, the pro for this approach is = rather limited - we achieve our goal.

The cons for this approach are = rather large:
- Major code changes
- Relays and servers need to be = changed at same time (otherwise changing servers does no good for = clients behind a relay)

- DHCP traffic is increased with = the client sending multiple Discovers (and servers perhaps sending = multiple offers) to find out whether a server can support the new = format.

3. Encapsulation.

We define a new encapsulation = option. In its simplest form, this option would encapsulate 16-bit = formatted options (formatted like DHCPv6 options). Using Ted Lemon's = new concatenation draft (draft-ietf-dhc-concat-*.txt), this = encapsulation option could easily be more than 255 bytes in length. In = other forms, perhaps we use a 16-bit option code by 8-bit length. Or we = us an ASN.1 like number encoding - each byte of the option tag and = option length encodes 7-bits of data and one bit specifies whether = another byte of tag (or length) follows.

The format for the basic option = is:

    = Code   Len      Extended option = 1       Extended option 2
   = +-----+-----+-----+-----+-----+-----+--- ... = ---+-----+-----+-----+-----+...
   | TBD | Len = |   ETAG1   |   ELEN1   | = EDATA1... |   ETAG2   |   = ELEN2   |...
   = +-----+-----+-----+-----+-----+-----+--- ... = ---+-----+-----+-----+-----+...

While any option COULD be = encapsulated, existing options (tag < 256) SHOULD NOT be = encapsulated (since they do not need to be).

A client that supports this = technique would advertise that fact to a server by including the tag = assigned to the encapsulation option in a Parameter Request List option = (55). A client would also include any 16-bit options it wanted by = encapsulating an "Extended Parameter Request List" option in = an encapsulation option (the client could of course include any = additional options as well). This "Extended Parameter Request = List" option would be a new option, assigned from the >255 tag = list, which is essentially identical to the existing Parameter Request = List option except that 16-bit option values are used.

Note: The "Extended = Parameter Request List" option could be a 8-bit option (which = would eliminate the need to encapsulate it).

The pros of this approach are = that no changes to existing clients and servers are needed (unless they = want to support new options >255). We can start assigning new = options and clients or servers that want to implement them can. No = impact to relays as they pass the options on as before (just data to = them). If new relay agent type options are needed, they too could be = assigned in the >255 range.

The cons of this approach are = minimal, when implementing the FIRST >255 option, additional client, = server, or relay work is needed. And, I guess to be fair, some bytes = are "wasted" in the encapsulation option overhead. But, = that's fairly minimal.


Of course, my preference is for = the Encapsulation technique (3).

If there are additional = techniques that might have been discussed in the past or that you think = of, or you feel that I've misrepresented the techniques, pros, or cons, = please comment.

- Bernie Volz
  Ericsson

------_=_NextPart_001_01C0B88D.F0FA5110-- From owner-dhcp-v6@bucknell.edu Thu Mar 29 18:32:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17904; Thu, 29 Mar 2001 18:32:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TNTle12412; Thu, 29 Mar 2001 18:29:47 -0500 (EST) 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 f2TNTie13469 for ; Thu, 29 Mar 2001 18:29:44 -0500 (EST) Received: from grosse.bisbee.fugue.com (p15.ns13.theriver.com [206.26.122.176]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2RBABE21346 for ; Tue, 27 Mar 2001 03:10:12 -0800 (PST) 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 f2TNR5s00833 for ; Thu, 29 Mar 2001 16:27:05 -0700 (MST) Message-Id: <200103292327.f2TNR5s00833@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: DHCP No-Go? Date: Thu, 29 Mar 2001 16:27:05 -0700 From: Ted Lemon 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 A user just made the suggestion I have quoted below on one of the ISC DHCP mailing lists. I thought about it for a while, and decided that it makes sense. We are in the right phase of protocol development to do this, and I think it would be easy. If the group is willing, I'll write up some language for it. Basically, what I'd suggest is that we say that if a DHCP server receives a DHCP Solicit message and knows that it's not going to give the client an address, it SHOULD send a DHCP Advertise message anyway, with no addresses for the IA proposed by the client and an error code saying why it isn't going to give the client an address. DHCP servers SHOULD be configurable to not respond to DHCP Solicits from clients they are configured not to serve. DHCP clients SHOULD ignore the DHCP Advertise message if it contains an error code, but MAY use the DHCP Advertise message to report status to the user if no non-error DHCP Advertise messages are received within the suggested timeout. Also, in DHCPv4 the server has the option of sending a text message along with the DHCPNAK. I think that it would be nice to provide this functionality in DHCPv6 as well, and to *strongly* suggest that DHCP clients present the information in the message to the user if no addresses are received. Right now, I know of no DHCPv4 clients that do this, although I know of several that can, and should. I think that this would provide a *much* better level of service for users of clients in cases where things are going wrong. I would again be happy to add text for this. In case anybody is feeling skeptical about my ability to deliver, BTW, I am about halfway through doing the stuff I said I'd do to the current draft and sending a diff. _MelloN_ Date: Fri, 30 Mar 2001 01:36:36 +0300 (EEST) From: =?iso-8859-1?Q?Martin-=C9ric_Racine?= To: dhcp-client@isc.org Subject: DHCPNOGO In-Reply-To: <200103290206.f2T26ij08578@grosse.bisbee.fugue.com> Message-ID: Reply-To: dhcp-client@isc.org List-unsubscribe: X-List-ID: *** From dhcp-client -- To unsubscribe, see the end of this message. *** On Wed, 28 Mar 2001, Ted Lemon wrote: > DHCP server will just ignore a DHCPDISCOVER if it doesn't > want to offer an address or doesn't have an address to offer. >From an end-user's perspective, an obvious to-do for the DHCP specification itself: * Add a DHCPNOGO message to acknowledge a received DHCPDISCOVER, in the event of a refusal or unability to offer an address. This would make it easier for end-users to rest assured that their configuration is not messed, they just cannot "login" for one reason or another. It would clear a lot of doubts, in any event of a failure to connect. -- Martin-Éric Racine, IT Consultant * http://funkyware.atari.org/ * May the Funk be with Q! * Author of the Atari TT030 Homepage. ----------------------------------------------------------------------- To unsubscribe from this list, visit http://www.isc.org/dhcp-lists.html or send mail to dhcp-client-request@isc.org with the subject line of 'unsubscribe'. ----------------------------------------------------------------------- --f2RAvKE21304.985690640/toccata.fugue.com-- From owner-dhcp-v6@bucknell.edu Thu Mar 29 18:32:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17941; Thu, 29 Mar 2001 18:32:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TNWMe08834; Thu, 29 Mar 2001 18:32:22 -0500 (EST) 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 f2TNW3e11477 for ; Thu, 29 Mar 2001 18:32:04 -0500 (EST) Received: from grosse.bisbee.fugue.com (p15.ns13.theriver.com [206.26.122.176]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2RBCWE21351 for ; Tue, 27 Mar 2001 03:12:32 -0800 (PST) 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 f2TNTUs00841 for ; Thu, 29 Mar 2001 16:29:30 -0700 (MST) Message-Id: <200103292329.f2TNTUs00841@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: DHCPINFORM Date: Thu, 29 Mar 2001 16:29:30 -0700 From: Ted Lemon 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 DHCPv4 has the DHCPINFORM message. DHCPv6 does not. We're solving this (I think) with DHCPsolicit/DHCPadvertise messages with no IAs, but I think this is confusing. I think we should just have a DHCP Information Request message that gets a DHCP Reply message with the requested information. If the group thinks this is a good plan, I'll write it up. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Mar 29 18:39:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18271 for ; Thu, 29 Mar 2001 18:39:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2TNZje05152; Thu, 29 Mar 2001 18:35:45 -0500 (EST) Received: from firewall.ma.virata.com (agranat.com [198.113.147.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2TNZbe00050 for ; Thu, 29 Mar 2001 18:35:38 -0500 (EST) Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id SAA12366 for ; Thu, 29 Mar 2001 18:35:22 -0500 Received: (from worley@localhost) by agranat.com (8.9.3/8.9.3) id SAA31579; Thu, 29 Mar 2001 18:35:22 -0500 Date: Thu, 29 Mar 2001 18:35:22 -0500 Message-Id: <200103292335.SAA31579@agranat.com> X-Authentication-Warning: alice.ma.virata.com: worley set sender to dworley@virata.com using -f From: Dale Worley To: DHCPv4 discussion list In-reply-to: <66F66129A77AD411B76200508B65AC694F9775@eambunt705.ena-east.ericsson.se> (Bernie.Volz@am1.ericsson.se) Subject: Re: DHCP Option Tag Exhaustion (1..127) References: <66F66129A77AD411B76200508B65AC694F9775@eambunt705.ena-east.ericsson.se> 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: "Bernie Volz (EUD)" This message is to start (or restart) the discussion (on the WG mailing list) around addressing the likely upcoming exhaustion of the DHCPv4 option space. I may be mistaken as to its significance, but there is a relevent item in: ftp://ftp.iana.org/in-notes/iana/assignments/bootp-dhcp-extensions/bootp-dhcp-option-126-127 The file itself is a copy of an e-mail request by Ralph E. Droms (who is one of the authors of RFC 2131 "DHCP Options and BOOTP Vendor Extensions") to allocate option codes 126 and 127 for extension purposes. (Much like proposal 3 in Volz' e-mail.) Given its placement in an IANA directory, I presumed that the assignment has been made, rather than merely proposed. Dale -- Dale R. WORLEY Project Manager - UPnP Virata Corp. Applications Infrastructure http://emweb.com From owner-dhcp-v6@bucknell.edu Fri Mar 30 00:00:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13087; Fri, 30 Mar 2001 00:00:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2U4v5e00566; Thu, 29 Mar 2001 23:57:05 -0500 (EST) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2U4uke00916 for ; Thu, 29 Mar 2001 23:56:46 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3att.ericy.com [138.85.92.10]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f2U4uT806894 for ; Thu, 29 Mar 2001 22:56:29 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2U4uT911377 for ; Thu, 29 Mar 2001 22:56:29 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Mar 29 22:56:28 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Mar 2001 22:56:28 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB8D1@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPINFORM Date: Thu, 29 Mar 2001 22:56:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B8D5.C6CC5A80" 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 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_001_01C0B8D5.C6CC5A80 Content-Type: text/plain; charset="iso-8859-1" There's also a DHCP Solicit and Request message without an IA. We should clarify what is and is not allowed/expected. Is a DHCPSolicit (or DHCPRequest) without an IA basically a DHCPINFORM? Or, do we not allow either of these to have no IA? Also, wasn't the original purpose to use the DHCPRequest to allow a client to get just configuration parameters (no addresses) - when no IA? Having multiple was to something isn't good, IMHO. Note with DHCPv4 there was NO way *NOT* to request an address without doing DHCPINFORM. With DHCPv6, that problem does not exist (do a Solicit or Request without an IA option). - Bernie Volz -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, March 29, 2001 6:30 PM To: DHCPv6 discussion list Subject: DHCPINFORM DHCPv4 has the DHCPINFORM message. DHCPv6 does not. We're solving this (I think) with DHCPsolicit/DHCPadvertise messages with no IAs, but I think this is confusing. I think we should just have a DHCP Information Request message that gets a DHCP Reply message with the requested information. If the group thinks this is a good plan, I'll write it up. _MelloN_ ------_=_NextPart_001_01C0B8D5.C6CC5A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPINFORM

There's also a DHCP Solicit and Request message = without an IA.

We should clarify what is and is not = allowed/expected. Is a DHCPSolicit (or DHCPRequest) without an IA = basically a DHCPINFORM? Or, do we not allow either of these to have no = IA?

Also, wasn't the original purpose to use the = DHCPRequest to allow a client to get just configuration parameters (no = addresses) - when no IA?

Having multiple was to something isn't good, = IMHO.

Note with DHCPv4 there was NO way *NOT* to request an = address without doing DHCPINFORM. With DHCPv6, that problem does not = exist (do a Solicit or Request without an IA option).

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, March 29, 2001 6:30 PM
To: DHCPv6 discussion list
Subject: DHCPINFORM



DHCPv4 has the DHCPINFORM message.   DHCPv6 = does not.   We're solving
this (I think) with DHCPsolicit/DHCPadvertise = messages with no IAs,
but I think this is confusing.   I think = we should just have a DHCP
Information Request message that gets a DHCP Reply = message with the
requested information.  If the group thinks = this is a good plan, I'll
write it up.

        =         =                _MelloN_

------_=_NextPart_001_01C0B8D5.C6CC5A80-- From owner-dhcp-v6@bucknell.edu Fri Mar 30 00:29:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16574; Fri, 30 Mar 2001 00:29:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2U5Sge12271; Fri, 30 Mar 2001 00:28:42 -0500 (EST) 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 f2U5SWe26901 for ; Fri, 30 Mar 2001 00:28:32 -0500 (EST) Received: from grosse.bisbee.fugue.com (a4.ns79.theriver.com [206.97.56.132]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2RH8uE22387 for ; Tue, 27 Mar 2001 09:08:58 -0800 (PST) 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 f2U5PQs01232 for ; Thu, 29 Mar 2001 22:25:26 -0700 (MST) Message-Id: <200103300525.f2U5PQs01232@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPINFORM In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 29 Mar 2001 22:56:26 CST." <66F66129A77AD411B76200508B65AC694CB8D1@eambunt705.ena-east.ericsson.se> Date: Thu, 29 Mar 2001 22:25:26 -0700 From: Ted Lemon 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 should clarify what is and is not allowed/expected. Is a > DHCPSolicit (or DHCPRequest) without an IA basically a DHCPINFORM? Or, > do we not allow either of these to have no IA? That's precisely the problem - it doesn't make sense for DHCPSolicit to be a DHCPINFORM, but it doesn't make sense for DHCPRequest to be DHCPINFORM either. I think DHCP Information Request ought to be seperate, because it's not a four-way handshake. > Also, wasn't the original purpose to use the DHCPRequest to allow a > client to get just configuration parameters (no addresses) - when no > IA? Yes, but my point is that we're overloading functionality on message types for no apparent reason. > Having multiple was to something isn't good, IMHO. I agree. Perhaps DHCPsolicit and DHCPrequest should not be valid without at least one IA option. > Note with DHCPv4 there was NO way *NOT* to request an address > without doing DHCPINFORM. With DHCPv6, that problem does not exist (do > a Solicit or Request without an IA option). Right, but because of the four-way handshake, the protocol without the DHCP Information Request message is confusing. Certainly we can define things in such a way that a careful read of the standard will cause an implementor to do the right thing, but it might be better to just define a seperate message for information requests not related to IAs, and that way even a careless read of the spec will produce the right results. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Mar 30 11:37:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24577; Fri, 30 Mar 2001 11:37:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UGYGe26570; Fri, 30 Mar 2001 11:34:16 -0500 (EST) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2UGY5e05117 for ; Fri, 30 Mar 2001 11:34:05 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3att.ericy.com [138.85.92.10]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f2UGXl827381 for ; Fri, 30 Mar 2001 10:33:48 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2UGXlL06547 for ; Fri, 30 Mar 2001 10:33:47 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Mar 30 10:33:46 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 10:33:46 -0600 Message-ID: <66F66129A77AD411B76200508B65AC694CB8D2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPINFORM Date: Fri, 30 Mar 2001 10:33:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B937.301CAF60" 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 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_001_01C0B937.301CAF60 Content-Type: text/plain; charset="iso-8859-1" Ted: The only problem I see is what if there are FUTURE resources other than IP Addresses? That is one reason that we carry address assignment requests in Options. So, I think this overloading is OK because it is still getting parameters (just that some are allocated and others are not). I think we can easily state something like: "If a host is not looking for allocated resources (IP addresses) then it may be sufficient to do just Solicit/Advertise (no need to do request/reply)."? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, March 30, 2001 12:25 AM To: DHCPv6 discussion list Subject: Re: DHCPINFORM > We should clarify what is and is not allowed/expected. Is a > DHCPSolicit (or DHCPRequest) without an IA basically a DHCPINFORM? Or, > do we not allow either of these to have no IA? That's precisely the problem - it doesn't make sense for DHCPSolicit to be a DHCPINFORM, but it doesn't make sense for DHCPRequest to be DHCPINFORM either. I think DHCP Information Request ought to be seperate, because it's not a four-way handshake. > Also, wasn't the original purpose to use the DHCPRequest to allow a > client to get just configuration parameters (no addresses) - when no > IA? Yes, but my point is that we're overloading functionality on message types for no apparent reason. > Having multiple was to something isn't good, IMHO. I agree. Perhaps DHCPsolicit and DHCPrequest should not be valid without at least one IA option. > Note with DHCPv4 there was NO way *NOT* to request an address > without doing DHCPINFORM. With DHCPv6, that problem does not exist (do > a Solicit or Request without an IA option). Right, but because of the four-way handshake, the protocol without the DHCP Information Request message is confusing. Certainly we can define things in such a way that a careful read of the standard will cause an implementor to do the right thing, but it might be better to just define a seperate message for information requests not related to IAs, and that way even a careless read of the spec will produce the right results. _MelloN_ ------_=_NextPart_001_01C0B937.301CAF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPINFORM

Ted:

The only problem I see is what if there are FUTURE = resources other than IP Addresses? That is one reason that we carry = address assignment requests in Options.

So, I think this overloading is OK because it is = still getting parameters (just that some are allocated and others are = not).

I think we can easily state something like: "If = a host is not looking for allocated resources (IP addresses) then it = may be sufficient to do just Solicit/Advertise (no need to do = request/reply)."?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, March 30, 2001 12:25 AM
To: DHCPv6 discussion list
Subject: Re: DHCPINFORM



> We should clarify what is and is not = allowed/expected. Is a
> DHCPSolicit (or DHCPRequest) without an IA = basically a DHCPINFORM? Or,
> do we not allow either of these to have no = IA?

That's precisely the problem - it doesn't make sense = for DHCPSolicit
to be a DHCPINFORM, but it doesn't make sense for = DHCPRequest to be
DHCPINFORM either.   I think DHCP = Information Request ought to be
seperate, because it's not a four-way = handshake.

> Also, wasn't the original purpose to use the = DHCPRequest to allow a
> client to get just configuration parameters (no = addresses) - when no
> IA?

Yes, but my point is that we're overloading = functionality on message
types for no apparent reason.

> Having multiple was to something isn't good, = IMHO.

I agree.   Perhaps DHCPsolicit and = DHCPrequest should not be valid
without at least one IA option.

> Note with DHCPv4 there was NO way *NOT* to = request an address
> without doing DHCPINFORM. With DHCPv6, that = problem does not exist (do
> a Solicit or Request without an IA = option).

Right, but because of the four-way handshake, the = protocol without the
DHCP Information Request message is = confusing.   Certainly we can
define things in such a way that a careful read of = the standard will
cause an implementor to do the right thing, but it = might be better to
just define a seperate message for information = requests not related to
IAs, and that way even a careless read of the spec = will produce the
right results.

        =         =                _MelloN_

------_=_NextPart_001_01C0B937.301CAF60-- From owner-dhcp-v4@bucknell.edu Fri Mar 30 11:45:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25089 for ; Fri, 30 Mar 2001 11:45:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UGfBe14521; Fri, 30 Mar 2001 11:41:11 -0500 (EST) Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UGf6e21677 for ; Fri, 30 Mar 2001 11:41:06 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 30 Mar 2001 08:39:32 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Mar 2001 08:39:32 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD552DDD@mailserver.sylantro.com> From: "Joe Aiello" To: DHCPv4 discussion list Subject: RE: DHCP Option Tag Exhaustion (1..127) Date: Fri, 30 Mar 2001 08:39:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 16DA694E267129-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B937.FEBD42D0" Reply-To: Joe.Aiello@sylantro.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_001_01C0B937.FEBD42D0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Option 3 seems a good choice. There is already a draft that is a good model (Ted's) and would provide a large number of new option codes. I assume IANA will still assign the options and may have a slight modification to their process. Folks like me who have requested a new option be assigned for their draft (draft-aiello-dhc-appliance-class-01.txt, and if you are interested in being a co-author or would like to provide some industry support, contact me), may have some relief in the having a new option assigned. I know, that was a shameless act of self interest... Thanks Bernie for bringing this up. -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 29, 2001 12:22 PM To: DHCPv4 discussion list Subject: DHCP Option Tag Exhaustion (1..127) Folks: This message is to start (or restart) the discussion (on the WG mailing list) around addressing the likely upcoming exhaustion of the DHCPv4 option space. As specified in RFC 2132: Option codes 128 to 254 (decimal) are reserved for site-specific options. Thus, we only have option codes 1 to 127 available for IETF specified options. Values 0 (pad) and 255 (end) are otherwise used [RFC 2132]. The most obvious solutions I believe are: 1. Expand the range of IETF specified options by reclaiming some range in the 128 to 254 range. 2. Use a new magic cookie value to specify a 16-bit option space. 3. Use one of the remaining unassigned option tags (<128) to encapsulate new 16-bit options (or perhaps simply to extend the option space by another 256 values). If there are other solutions, it would be useful for these to be discussed as well. Here's some initial comments on the solutions listed above proposed: 1. Expand the range of the IETF specified options by reclaiming some space in the 128 to 254 range. This would require collecting information on which values are currently in use (unless that usage is very self contained and easily redeployable to a different value). For example, Microsoft uses several values in their products which would be difficult to change because of the large number of hosts in the market. Perhaps the range from 160 to 223 may be available (that is based on my probably incorrect belief that people would start at one end of the range or the other). The pro for this approach is that it really requires no code changes in clients or servers (other than to implement the new options when they are defined). The con for this approach is we might not learn of all of the options in use and therefore cause a collision with an existing option. 2. Use a new magic cookie to specify a 16-bit option space. This seems fairly straight forward in theory. If the new magic cookie appears in a DHCP (BOOTP) packet, the new client and server simply use the 16-bit option format proposed for DHCPv6 (16-bit tag followed by 16-bit data length following by the data). Options 0 to 255 would retain their same meaning whether in the 8-bit or 16-bit format. One issue is how do the client / relay / server negotiate the use of the new format? Does the client send a Discover with the new magic cookie and if it receives no replies after some number of attempts, fall back to the old magic cookie? Does it send two Discovers (one with new and one with old)? If a relay receives a packet with the new cookie, it won't forward it(?). Thus, this requires that both relays and servers be upgraded in order for the new format to be available to servers behind relays? And, of course this requires fairly substantial code changes in clients, relays, and servers. So, the pro for this approach is rather limited - we achieve our goal. The cons for this approach are rather large: - Major code changes - Relays and servers need to be changed at same time (otherwise changing servers does no good for clients behind a relay) - DHCP traffic is increased with the client sending multiple Discovers (and servers perhaps sending multiple offers) to find out whether a server can support the new format. 3. Encapsulation. We define a new encapsulation option. In its simplest form, this option would encapsulate 16-bit formatted options (formatted like DHCPv6 options). Using Ted Lemon's new concatenation draft (draft-ietf-dhc-concat-*.txt), this encapsulation option could easily be more than 255 bytes in length. In other forms, perhaps we use a 16-bit option code by 8-bit length. Or we us an ASN.1 like number encoding - each byte of the option tag and option length encodes 7-bits of data and one bit specifies whether another byte of tag (or length) follows. The format for the basic option is: Code Len Extended option 1 Extended option 2 +-----+-----+-----+-----+-----+-----+--- ... ---+-----+-----+-----+-----+... | TBD | Len | ETAG1 | ELEN1 | EDATA1... | ETAG2 | ELEN2 |... +-----+-----+-----+-----+-----+-----+--- ... ---+-----+-----+-----+-----+... While any option COULD be encapsulated, existing options (tag < 256) SHOULD NOT be encapsulated (since they do not need to be). A client that supports this technique would advertise that fact to a server by including the tag assigned to the encapsulation option in a Parameter Request List option (55). A client would also include any 16-bit options it wanted by encapsulating an "Extended Parameter Request List" option in an encapsulation option (the client could of course include any additional options as well). This "Extended Parameter Request List" option would be a new option, assigned from the >255 tag list, which is essentially identical to the existing Parameter Request List option except that 16-bit option values are used. Note: The "Extended Parameter Request List" option could be a 8-bit option (which would eliminate the need to encapsulate it). The pros of this approach are that no changes to existing clients and servers are needed (unless they want to support new options >255). We can start assigning new options and clients or servers that want to implement them can. No impact to relays as they pass the options on as before (just data to them). If new relay agent type options are needed, they too could be assigned in the >255 range. The cons of this approach are minimal, when implementing the FIRST >255 option, additional client, server, or relay work is needed. And, I guess to be fair, some bytes are "wasted" in the encapsulation option overhead. But, that's fairly minimal. Of course, my preference is for the Encapsulation technique (3). If there are additional techniques that might have been discussed in the past or that you think of, or you feel that I've misrepresented the techniques, pros, or cons, please comment. - Bernie Volz Ericsson ------_=_NextPart_001_01C0B937.FEBD42D0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable DHCP Option Tag Exhaustion (1..127)

Option 3 seems a good choice.  = There is already a draft that is a good model (Ted's) and would provide a large number = of new option codes.  I assume = IANA will still assign the options and may have a slight modification to their = process.

 

=

Folks like me who have requested a new option be  assigned for their draft = (draft-aiello-dhc-appliance-class-01.txt, and if you are interested in being a co-author or would like to provide = some industry support, contact me), may have some relief  in the having a new option assigned.  I know, that was a shameless = act of self interest…

 

=

Thanks Bernie for bringing this up.

 

=

 

=

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, March = 29, 2001 12:22 PM
To: DHCPv4 discussion = list
Subject: DHCP Option Tag Exhaustion (1..127)

 

Folks:

This message is to start (or = restart) the discussion (on the WG mailing list) around addressing the likely = upcoming exhaustion of the DHCPv4 option space. As specified in RFC = 2132:=

        = Option codes 128 to 254 (decimal) are = reserved for site-specific options. =

Thus, we only have option codes = 1 to 127 available for IETF specified options. Values 0 (pad) and 255 (end) are otherwise used [RFC 2132].=

The most obvious solutions I = believe are:
1. = Expand the range of IETF specified options by reclaiming some range in the 128 to = 254 range. =
2. Use = a new magic cookie value to specify a 16-bit option space.
3. Use = one of the remaining unassigned option tags (<128) to encapsulate new = 16-bit options (or perhaps simply to extend the option space by another 256 = values).=

If there are other solutions, it = would be useful for these to be discussed as well.

Here's some initial comments on = the solutions listed above proposed:

1. Expand the range of the IETF specified options by reclaiming some space in the 128 to 254 = range. =

This would require collecting information on which values are currently in use (unless that usage is = very self contained and easily redeployable to a different value). For = example, Microsoft uses several values in their products which would be = difficult to change because of the large number of hosts in the = market.=

Perhaps the range from 160 to = 223 may be available (that is based on my probably incorrect belief that people = would start at one end of the range or the other).=

The pro for this approach is = that it really requires no code changes in clients or servers (other than to = implement the new options when they are defined).=

The con for this approach is we = might not learn of all of the options in use and therefore cause a collision = with an existing option.

2. Use a new magic cookie to = specify a 16-bit option space. =

This seems fairly straight = forward in theory. If the new magic cookie appears in a DHCP (BOOTP) packet, the = new client and server simply use the 16-bit option format proposed for = DHCPv6 (16-bit tag followed by 16-bit data length following by the data). = Options 0 to 255 would retain their same meaning whether in the 8-bit or 16-bit = format.=

One issue is how do the client / = relay / server negotiate the use of the new format? Does the client send a = Discover with the new magic cookie and if it receives no replies after some = number of attempts, fall back to the old magic cookie? Does it send two Discovers = (one with new and one with old)? If a relay receives a packet with the new = cookie, it won't forward it(?). Thus, this requires that both relays and = servers be upgraded in order for the new format to be available to servers behind = relays?=

And, of course this requires = fairly substantial code changes in clients, relays, and = servers. =

So, the pro for this approach is = rather limited - we achieve our goal.

The cons for this approach are = rather large: =
- = Major code changes =
- = Relays and servers need to be changed at same time (otherwise changing servers = does no good for clients behind a relay)=

- DHCP traffic is increased with = the client sending multiple Discovers (and servers perhaps sending multiple = offers) to find out whether a server can support the new = format.=

3. = Encapsulation. =

We define a new encapsulation = option. In its simplest form, this option would encapsulate 16-bit formatted = options (formatted like DHCPv6 options). Using Ted Lemon's new concatenation = draft (draft-ietf-dhc-concat-*.txt), this encapsulation option could easily = be more than 255 bytes in length. In other forms, perhaps we use a 16-bit = option code by 8-bit length. Or we us an ASN.1 like number encoding - each byte of = the option tag and option length encodes 7-bits of data and one bit = specifies whether another byte of tag (or length) follows.=

The format for the basic option = is: =

    = Code   Len      Extended option 1       Extended option = 2
   +-----+-----+-----+-----+-----+-----+--- ... = ---+-----+-----+-----+-----+...
   | TBD | Len |   ETAG1   |   = ELEN1   | EDATA1... |   ETAG2   |   = ELEN2   |...
   +-----+-----+-----+-----+-----+-----+--- ... = ---+-----+-----+-----+-----+... =

While any option COULD be = encapsulated, existing options (tag < 256) SHOULD NOT be encapsulated (since they = do not need to be).

A client that supports this = technique would advertise that fact to a server by including the tag assigned to = the encapsulation option in a Parameter Request List option (55). A client = would also include any 16-bit options it wanted by encapsulating an = "Extended Parameter Request List" option in an encapsulation option (the = client could of course include any additional options as well). This = "Extended Parameter Request List" option would be a new option, assigned = from the >255 tag list, which is essentially identical to the existing = Parameter Request List option except that 16-bit option values are = used.=

Note: The "Extended = Parameter Request List" option could be a 8-bit option (which would = eliminate the need to encapsulate it).

The pros of this approach are = that no changes to existing clients and servers are needed (unless they want to = support new options >255). We can start assigning new options and clients or = servers that want to implement them can. No impact to relays as they pass the = options on as before (just data to them). If new relay agent type options are = needed, they too could be assigned in the >255 range.=

The cons of this approach are = minimal, when implementing the FIRST >255 option, additional client, server, = or relay work is needed. And, I guess to be fair, some bytes are = "wasted" in the encapsulation option overhead. But, that's fairly = minimal.=

 =

Of course, my preference is for = the Encapsulation technique (3).

If there are additional = techniques that might have been discussed in the past or that you think of, or you feel = that I've misrepresented the techniques, pros, or cons, please = comment.=

- Bernie Volz
  = Ericsson =

------_=_NextPart_001_01C0B937.FEBD42D0-- From owner-dhcp-v4@bucknell.edu Fri Mar 30 12:58:53 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00088 for ; Fri, 30 Mar 2001 12:58:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UHrSe02812; Fri, 30 Mar 2001 12:53:28 -0500 (EST) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch2.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2UHrIe09914 for ; Fri, 30 Mar 2001 12:53:18 -0500 (EST) Received: by fs-sd-exch2.coppermountain.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 09:53:25 -0800 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C8035BACA7@fs-sd-exch2.coppermountain.com> From: emichelsen@coppermountain.com To: DHCPv4 discussion list Subject: RE: DHCP Option Tag Exhaustion (1..127) Date: Fri, 30 Mar 2001 09:53:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Using option 3 still leaves the problem of proprietary options, such as that described with Microsoft. A while ago, I proposed an OUI or enterprise-id based extension, kind of like SNAP. This format solves both problems: new address space for option tags, and guaranteed unique tags for proprietary stuff. It could work like this: +-----+-----+-----+-----+-----+-----+-----+ | tag | len | enterp-id | data... | +-----+-----+-----+-----+-----+-----+-----+ IANA could use an enterprise-id of zero. IANA assigned "data" fields would be coded as are the existing options: tag,len,value. Smart enterprises would do the same. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks -----Original Message----- From: Joe Aiello [mailto:Joe.Aiello@sylantro.com] Sent: Friday, March 30, 2001 8:40 To: DHCPv4 discussion list Subject: RE: DHCP Option Tag Exhaustion (1..127) Option 3 seems a good choice. There is already a draft that is a good model (Ted's) and would provide a large number of new option codes. I assume IANA will still assign the options and may have a slight modification to their process. Folks like me who have requested a new option be assigned for their draft (draft-aiello-dhc-appliance-class-01.txt, and if you are interested in being a co-author or would like to provide some industry support, contact me), may have some relief in the having a new option assigned. I know, that was a shameless act of self interest... Thanks Bernie for bringing this up. -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, March 29, 2001 12:22 PM To: DHCPv4 discussion list Subject: DHCP Option Tag Exhaustion (1..127) Folks: This message is to start (or restart) the discussion (on the WG mailing list) around addressing the likely upcoming exhaustion of the DHCPv4 option space. As specified in RFC 2132: Option codes 128 to 254 (decimal) are reserved for site-specific options. Thus, we only have option codes 1 to 127 available for IETF specified options. Values 0 (pad) and 255 (end) are otherwise used [RFC 2132]. The most obvious solutions I believe are: 1. Expand the range of IETF specified options by reclaiming some range in the 128 to 254 range. 2. Use a new magic cookie value to specify a 16-bit option space. 3. Use one of the remaining unassigned option tags (<128) to encapsulate new 16-bit options (or perhaps simply to extend the option space by another 256 values). If there are other solutions, it would be useful for these to be discussed as well. Here's some initial comments on the solutions listed above proposed: 1. Expand the range of the IETF specified options by reclaiming some space in the 128 to 254 range. This would require collecting information on which values are currently in use (unless that usage is very self contained and easily redeployable to a different value). For example, Microsoft uses several values in their products which would be difficult to change because of the large number of hosts in the market. Perhaps the range from 160 to 223 may be available (that is based on my probably incorrect belief that people would start at one end of the range or the other). The pro for this approach is that it really requires no code changes in clients or servers (other than to implement the new options when they are defined). The con for this approach is we might not learn of all of the options in use and therefore cause a collision with an existing option. 2. Use a new magic cookie to specify a 16-bit option space. This seems fairly straight forward in theory. If the new magic cookie appears in a DHCP (BOOTP) packet, the new client and server simply use the 16-bit option format proposed for DHCPv6 (16-bit tag followed by 16-bit data length following by the data). Options 0 to 255 would retain their same meaning whether in the 8-bit or 16-bit format. One issue is how do the client / relay / server negotiate the use of the new format? Does the client send a Discover with the new magic cookie and if it receives no replies after some number of attempts, fall back to the old magic cookie? Does it send two Discovers (one with new and one with old)? If a relay receives a packet with the new cookie, it won't forward it(?). Thus, this requires that both relays and servers be upgraded in order for the new format to be available to servers behind relays? And, of course this requires fairly substantial code changes in clients, relays, and servers. So, the pro for this approach is rather limited - we achieve our goal. The cons for this approach are rather large: - Major code changes - Relays and servers need to be changed at same time (otherwise changing servers does no good for clients behind a relay) - DHCP traffic is increased with the client sending multiple Discovers (and servers perhaps sending multiple offers) to find out whether a server can support the new format. 3. Encapsulation. We define a new encapsulation option. In its simplest form, this option would encapsulate 16-bit formatted options (formatted like DHCPv6 options). Using Ted Lemon's new concatenation draft (draft-ietf-dhc-concat-*.txt), this encapsulation option could easily be more than 255 bytes in length. In other forms, perhaps we use a 16-bit option code by 8-bit length. Or we us an ASN.1 like number encoding - each byte of the option tag and option length encodes 7-bits of data and one bit specifies whether another byte of tag (or length) follows. The format for the basic option is: Code Len Extended option 1 Extended option 2 +-----+-----+-----+-----+-----+-----+--- ... ---+-----+-----+-----+-----+... | TBD | Len | ETAG1 | ELEN1 | EDATA1... | ETAG2 | ELEN2 |... +-----+-----+-----+-----+-----+-----+--- ... ---+-----+-----+-----+-----+... While any option COULD be encapsulated, existing options (tag < 256) SHOULD NOT be encapsulated (since they do not need to be). A client that supports this technique would advertise that fact to a server by including the tag assigned to the encapsulation option in a Parameter Request List option (55). A client would also include any 16-bit options it wanted by encapsulating an "Extended Parameter Request List" option in an encapsulation option (the client could of course include any additional options as well). This "Extended Parameter Request List" option would be a new option, assigned from the >255 tag list, which is essentially identical to the existing Parameter Request List option except that 16-bit option values are used. Note: The "Extended Parameter Request List" option could be a 8-bit option (which would eliminate the need to encapsulate it). The pros of this approach are that no changes to existing clients and servers are needed (unless they want to support new options >255). We can start assigning new options and clients or servers that want to implement them can. No impact to relays as they pass the options on as before (just data to them). If new relay agent type options are needed, they too could be assigned in the >255 range. The cons of this approach are minimal, when implementing the FIRST >255 option, additional client, server, or relay work is needed. And, I guess to be fair, some bytes are "wasted" in the encapsulation option overhead. But, that's fairly minimal. Of course, my preference is for the Encapsulation technique (3). If there are additional techniques that might have been discussed in the past or that you think of, or you feel that I've misrepresented the techniques, pros, or cons, please comment. - Bernie Volz Ericsson From owner-dhcp-v4@bucknell.edu Fri Mar 30 13:10:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01051 for ; Fri, 30 Mar 2001 13:10:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UI6te26561; Fri, 30 Mar 2001 13:06:55 -0500 (EST) 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 f2UI5Xe31998 for ; Fri, 30 Mar 2001 13:05:34 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-151.cisco.com [161.44.149.151]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21742 for ; Fri, 30 Mar 2001 13:05:14 -0500 (EST) Message-Id: <4.3.2.7.2.20010330125458.03693008@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Mar 2001 13:04:52 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: DHCP Option Tag Exhaustion (1..127) In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD552DDD@mailserver.sylantro .com> 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 Option 3 has already been considered and rejected by the WG. I wrote the draft using tags 126 and 127 to expand the existing address space through encapsulation. The WG consensus was that option 2 is the right way to go and we have a draft describing a new option code space. It's not clear we are in an emergency yet. There are 10-15 option codes that were reserved before the current option assignment rules (BCP 43, RFC 2939) were put in place but were never formally assigned to an option (usually because the option was never accepted as a Proposed Standard). I started to go through the list of assigned option codes once upon a time but never followed through to submit a list to IANA of codes that could be reassigned. - Ralph At 08:39 AM 3/30/2001 -0800, Joe Aiello wrote: >Option 3 seems a good choice. There is already a draft that is a good >model (Ted's) and would provide a large number of new option codes. I >assume IANA will still assign the options and may have a slight >modification to their process. > > > >Folks like me who have requested a new option be assigned for their draft >(draft-aiello-dhc-appliance-class-01.txt, and if you are interested in >being a co-author or would like to provide some industry support, contact >me), may have some relief I know, that was a shameless act of self interest& > > > >Thanks Bernie for bringing this up. > > > > > >-----Original Message----- >From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] >Sent: Thursday, March 29, 2001 12:22 PM >To: DHCPv4 discussion list >Subject: DHCP Option Tag Exhaustion (1..127) > > > >Folks: > >This message is to start (or restart) the discussion (on the WG mailing >list) around addressing the likely upcoming exhaustion of the DHCPv4 >option space. As specified in RFC 2132: > > Option codes 128 to 254 (decimal) are reserved for site-specific > options. > >Thus, we only have option codes 1 to 127 available for IETF specified >options. Values 0 (pad) and 255 (end) are otherwise used [RFC 2132]. > >The most obvious solutions I believe are: >1. Expand the range of IETF specified options by reclaiming some range in >the 128 to 254 range. >2. Use a new magic cookie value to specify a 16-bit option space. >3. Use one of the remaining unassigned option tags (<128) to encapsulate >new 16-bit options (or perhaps simply to extend the option space by >another 256 values). > >If there are other solutions, it would be useful for these to be discussed >as well. > >Here's some initial comments on the solutions listed above proposed: > >1. Expand the range of the IETF specified options by reclaiming some space >in the 128 to 254 range. > >This would require collecting information on which values are currently in >use (unless that usage is very self contained and easily redeployable to a >different value). For example, Microsoft uses several values in their >products which would be difficult to change because of the large number of >hosts in the market. > >Perhaps the range from 160 to 223 may be available (that is based on my >probably incorrect belief that people would start at one end of the range >or the other). > >The pro for this approach is that it really requires no code changes in >clients or servers (other than to implement the new options when they are >defined). > >The con for this approach is we might not learn of all of the options in >use and therefore cause a collision with an existing option. > >2. Use a new magic cookie to specify a 16-bit option space. > >This seems fairly straight forward in theory. If the new magic cookie >appears in a DHCP (BOOTP) packet, the new client and server simply use the >16-bit option format proposed for DHCPv6 (16-bit tag followed by 16-bit >data length following by the data). Options 0 to 255 would retain their >same meaning whether in the 8-bit or 16-bit format. > >One issue is how do the client / relay / server negotiate the use of the >new format? Does the client send a Discover with the new magic cookie and >if it receives no replies after some number of attempts, fall back to the >old magic cookie? Does it send two Discovers (one with new and one with >old)? If a relay receives a packet with the new cookie, it won't forward >it(?). Thus, this requires that both relays and servers be upgraded in >order for the new format to be available to servers behind relays? > >And, of course this requires fairly substantial code changes in clients, >relays, and servers. > >So, the pro for this approach is rather limited - we achieve our goal. > >The cons for this approach are rather large: >- Major code changes >- Relays and servers need to be changed at same time (otherwise changing >servers does no good for clients behind a relay) > >- DHCP traffic is increased with the client sending multiple Discovers >(and servers perhaps sending multiple offers) to find out whether a server >can support the new format. > >3. Encapsulation. > >We define a new encapsulation option. In its simplest form, this option >would encapsulate 16-bit formatted options (formatted like DHCPv6 >options). Using Ted Lemon's new concatenation draft >(draft-ietf-dhc-concat-*.txt), this encapsulation option could easily be >more than 255 bytes in length. In other forms, perhaps we use a 16-bit >option code by 8-bit length. Or we us an ASN.1 like number encoding - each >byte of the option tag and option length encodes 7-bits of data and one >bit specifies whether another byte of tag (or length) follows. > >The format for the basic option is: > > Code Len Extended option 1 Extended option 2 > +-----+-----+-----+-----+-----+-----+--- ... > ---+-----+-----+-----+-----+... > | TBD | Len | ETAG1 | ELEN1 | EDATA1... > | ETAG2 | ELEN2 |... > +-----+-----+-----+-----+-----+-----+--- ... > ---+-----+-----+-----+-----+... > >While any option COULD be encapsulated, existing options (tag < 256) >SHOULD NOT be encapsulated (since they do not need to be). > >A client that supports this technique would advertise that fact to a >server by including the tag assigned to the encapsulation option in a >Parameter Request List option (55). A client would also include any 16-bit >options it wanted by encapsulating an "Extended Parameter Request List" >option in an encapsulation option (the client could of course include any >additional options as well). This "Extended Parameter Request List" option >would be a new option, assigned from the >255 tag list, which is >essentially identical to the existing Parameter Request List option except >that 16-bit option values are used. > >Note: The "Extended Parameter Request List" option could be a 8-bit option >(which would eliminate the need to encapsulate it). > >The pros of this approach are that no changes to existing clients and >servers are needed (unless they want to support new options >255). We can >start assigning new options and clients or servers that want to implement >them can. No impact to relays as they pass the options on as before (just >data to them). If new relay agent type options are needed, they too could >be assigned in the >255 range. > >The cons of this approach are minimal, when implementing the FIRST >255 >option, additional client, server, or relay work is needed. And, I guess >to be fair, some bytes are "wasted" in the encapsulation option overhead. >But, that's fairly minimal. > > > >Of course, my preference is for the Encapsulation technique (3). > >If there are additional techniques that might have been discussed in the >past or that you think of, or you feel that I've misrepresented the >techniques, pros, or cons, please comment. > >- Bernie Volz > Ericsson From owner-dhcp-v6@bucknell.edu Fri Mar 30 14:04:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05531; Fri, 30 Mar 2001 14:04:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UJ1Ve23750; Fri, 30 Mar 2001 14:01:31 -0500 (EST) 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 f2UJ1Pe15235 for ; Fri, 30 Mar 2001 14:01:25 -0500 (EST) Received: from grosse.bisbee.fugue.com (az-ben-pm3-2-29.ppp.theriver.com [206.25.50.29]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f2S6fqE23126 for ; Tue, 27 Mar 2001 22:41:52 -0800 (PST) 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 f2UIwN700341 for ; Fri, 30 Mar 2001 11:58:23 -0700 (MST) Message-Id: <200103301858.f2UIwN700341@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPINFORM In-Reply-To: Message from "Bernie Volz (EUD)" of "Fri, 30 Mar 2001 10:33:44 CST." <66F66129A77AD411B76200508B65AC694CB8D2@eambunt705.ena-east.ericsson.se> Date: Fri, 30 Mar 2001 11:58:23 -0700 From: Ted Lemon 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 only problem I see is what if there are FUTURE resources other > than IP Addresses? That is one reason that we carry address assignment > requests in Options. Seems like we could address that when we write this future specification. > So, I think this overloading is OK because it is still getting > parameters (just that some are allocated and others are not). But there is no need for a four-way handshake for just getting parameters. > I think we can easily state something like: "If a host is not > looking for allocated resources (IP addresses) then it may be > sufficient to do just Solicit/Advertise (no need to do > request/reply)."? Of course. The question I am raising is, "does this make sense?" And my answer is "no." I realize that this is how we have proposed to do things. I am asking whether or not it makes sense. I think it's confusing. We could write in the spec that DHCPReconfirm was just a DHCPRequest with slightly different parameters, but we don't do that because it's confusing. This case is similar. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Mar 30 15:05:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10474 for ; Fri, 30 Mar 2001 15:05:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UJxDe32655; Fri, 30 Mar 2001 14:59:13 -0500 (EST) Received: from mail.ultradns.com (IDENT:qmailr@mail.ultradns.net [216.15.7.199]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UJx2e23823 for ; Fri, 30 Mar 2001 14:59:02 -0500 (EST) Received: (qmail 22156 invoked from network); 30 Mar 2001 19:59:01 -0000 Received: from linuxdev1-firewall (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 30 Mar 2001 19:59:01 -0000 From: "Richard Barr Hibbs" To: DHCPv4 discussion list Subject: RE: DHCP Option Tag Exhaustion (1..127) Date: Fri, 30 Mar 2001 11:59:05 -0800 Message-ID: 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.2.7.2.20010330125458.03693008@mail.bucknell.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ralph Droms > Sent: Friday, March 30, 2001 10:05 AM > > It's not clear we are in an emergency yet. There are 10-15 option codes > that were reserved before the current option assignment rules > (BCP 43, RFC 2939) were put in place but were never formally assigned to > an option (usually because the option was never accepted as a Proposed > Standard). I started to go through the list of assigned option codes once > upon a time but never followed through to submit a list to IANA of codes > that could be reassigned. > I've forgotten now how long ago I proposed two possible ways of obtaining relief that were rejected by voice vote at a Working Group meeting, but I'm going to throw them out again to the mailing list. 1. Establish "Sunset" rules for DHCPv4 Options Certain options are absolutely required by the base protocol, but many are simply convenience items. Examples include things like "Default IRC Server." For non-mandatory options, IANA could establish a sunset date, say 5 years after adoption of the option code. At the sunset date, any option which could not muster support (based on actual usage) would be retired, and its code available for reuse. This approach has a number of problems, as pointed out by Thomas Narten, not the least of which is burdening IANA with yet another task, and the necessity of making each non-mandatory option a separate RFC to have individual control over the assigned option codes. It has the distinct advantage of preventing the v4 option space from becoming bloated over time with unused and forgotten options. 2. Establish a "Demonstrated Use" Rule for New Options When a new option is proposed in an Internet-Draft, it's status would be "Experimental" rather than "Standards Track" until a minimum number of interoperable implementations (for example, three) could be demonstrated. Only then would the option be promoted to "Standards Track" status, thus permitting easy reclamation and reuse of options that seemed like a good idea, but which don't make it into actual usage. This has the disadvantage of lengthening the document cycle, but it does have a built-in regulatory mechanism in the form of demonstrable, interoperable implementations. ----- Neither of these proposals diminishes the value of considering how we could significantly enlarge the v4 option space, but there is also the ugly question of should be trying to extend the useful life of DHCPv4 at all? Doesn't that reduce the likelihood of DHCPv6 being adopted widely? That is also something we should perhaps debate here. --Barr Hibbs UltraDNS Corporation From owner-dhcp-v4@bucknell.edu Fri Mar 30 15:05:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10495 for ; Fri, 30 Mar 2001 15:05:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2UK1we03466; Fri, 30 Mar 2001 15:01:58 -0500 (EST) 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 f2UK1be08920 for ; Fri, 30 Mar 2001 15:01:37 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA32748 for ; Fri, 30 Mar 2001 15:01:18 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA26810 for ; Fri, 30 Mar 2001 15:01:20 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA07334 for ; Fri, 30 Mar 2001 14:57:41 -0500 Message-Id: <200103301957.OAA07334@rotala.raleigh.ibm.com> To: DHCPv4 discussion list Subject: FWD: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Date: Fri, 30 Mar 2001 14:57:40 -0500 From: Thomas Narten 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 Any comments on this document from this WG? ------- Forwarded Message From: The IESG To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com Date: Fri, 30 Mar 2001 11:14:14 -0500 SUBJECT: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Reply-to: iesg@ietf.org The IESG has received a request from the IP Security Protocol Working Group to consider DHCPv4 Configuration of IPSEC Tunnel Mode as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 13, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-09.txt ------- End of Forwarded Message From owner-dhcp-v6@bucknell.edu Sat Mar 31 07:19:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28916; Sat, 31 Mar 2001 07:19:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f2VCEoe06453; Sat, 31 Mar 2001 07:14:50 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f2VCEXe27428 for ; Sat, 31 Mar 2001 07:14:34 -0500 (EST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA08676; Sat, 31 Mar 2001 21:15:40 +0900 (JST) Date: Sat, 31 Mar 2001 13:49:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: DHCPv6 discussion list Cc: aboba@internaut.com, jim.bound@nokia.com, deering@cisco.com, erik.guttman@sun.com, itojun@iijlab.net, hinden@IPRG.NOKIA.COM, onoe@sm.sony.co.jp, hesham.soliman@ericsson.com, dthaler@MICROSOFT.COM Subject: Re: draft-ietf-ipngwg-dns-discovery-00.txt In-Reply-To: <66F66129A77AD411B76200508B65AC694F9776@eambunt705.ena-east.ericsson.se> References: <66F66129A77AD411B76200508B65AC694F9776@eambunt705.ena-east.ericsson.se> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 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, 29 Mar 2001 14:22:16 -0600, >>>>> "Bernie Volz (EUD)" said: > Regarding the discussion at the DHC WG at the Minneapolis IETF on > Wednesday (on DHCPv6) on draft-ietf-ipngwg-dns-discovery-00.txt (and > the design team), why was the idea of using a DHCP server > eliminated? Seems to me like that's the simplest way? I agree it > isn't possible today because we haven't finished the DHCPv6 work. > However, you're going to do this requires some code to > implement. So, why not just develop mini-DHCPv6 servers. A DNS > server system may include a mini-DHCPv6 server which responds with > only configuration parameters. A Router, if not configured as a DHCP > relay, may also have a mini-DHCPv6 server. My understanding (other team members may have different opinions) is that we simply do not want to rely on other mechanisms than DNS itself. p.s. jinmei@isl.rdc.toshiba.com.toshiba.co.jp, which was in the "To:" list in your original message, was wrong. The correct one is jinmei@isl.rdc.toshiba.co.jp. Probably I could receive the message as a subscriber of the dhcp-v6 list...