From mailman-owner@ietf.org Tue Jan 1 05:01:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09164 for ; Tue, 1 Jan 2002 05:01:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28684 for ; Tue, 1 Jan 2002 05:01:56 -0500 (EST) Date: Tue, 1 Jan 2002 05:01:56 -0500 (EST) Message-Id: <200201011001.FAA28684@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org From dhcwg-admin@ietf.org Wed Jan 2 01:29:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21916; Wed, 2 Jan 2002 01:29:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25503; Wed, 2 Jan 2002 01:24:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25479 for ; Wed, 2 Jan 2002 01:24:30 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21904 for ; Wed, 2 Jan 2002 01:24:24 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Wed, 2 Jan 2002 15:26:46 +0900 From: "Dany JUNG" To: Date: Wed, 2 Jan 2002 15:23:59 +0900 Message-ID: <000001c19356$10cee6b0$c3192dd3@sun> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C193A1.80B68EB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [dhcwg] About draft No. 22 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C193A1.80B68EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all~ While I was reading draft-22.txt, I got to have several questions. I would like to ask you all and share information as a fellow from now on. I have been an observer, although this is a great community. I would love to work more actively. 1. Why does Reply message have DUID option in this chart? B. Appearance of Options in Message Types The following table indicates with a "*" the options are allowed in each DHCP message type: DUID IA RTA ORO Pref Time Client Server DSTM DSTM Forw. Forw. Addr Tunn Solicit * * * * Advert. * * * * * * * Request * * * * Confirm * * * * Renew * * * * Rebind * * * * Decline * * * * Release * * * * Reply * * * * * * * Reconf. * * Inform. * * R-forw. * * R-repl. * * 2. What do you configure for reply message's options if you are questioned to assign IPv6 address and IPv4 address for DSTM in request message simultaneously ? Options of Reply message are as follow -IA option -IA Address option -DSTM Global IPv4 address option -IA option (for IPv4-mapped IPv6 address) -IA Address option (for IPv4-mapped IPv6 address) Is this possible?? To work more actively, I am going to ask you more questions, and look forward to hearing from you. I will try to reply your questions as many as I can. Have a nice day !! ------=_NextPart_000_0001_01C193A1.80B68EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all~

 

While I was reading draft-22.txt, I got to = have several questions.

I would like to ask you all and share = information as a fellow from now on.

I have been an observer, although this is a = great community.

I would love to work more = actively.

 

1. Why does Reply message have DUID option in = this chart?

 

 B. Appearance of Options in Message Types

 

   = The following table indicates with a "*" the options are allowed = in

   = each DHCP message = type:

 

 

        DUID   IA    RTA   ORO  Pref  Time Client Server DSTM  = DSTM

       &nbs= p;            = ;            =              Forw.  Forw. Addr  = Tunn

Solicit    *     *     *     = *

Advert.    *     *     *       &nbs= p;   *     = *       &nbs= p;         *     = *

Request    *     *     *     = *

Confirm     *     *     *     = *

Renew      *     *     *     = *

Rebind     *     *     *     = *

Decline    *     *     *     = *

Release    *     *     *     = *

Reply      *     *     *       &nbs= p;   *     = *       &nbs= p;         *     = *

Reconf.    = *       &nbs= p;         *

Inform.    *       &nbs= p;         *

R-forw.       &nbs= p;            = ;            =         *     = *

R-repl.       &nbs= p;            = ;            =         *     = *

 

 

2. What do you configure for reply message's = options if you are questioned to assign IPv6 address and =

IPv4 address for DSTM in request message = simultaneously ?

 

 

Options of Reply message are as = follow

-IA option

-IA Address = option

-DSTM Global IPv4 address = option

-IA option (for IPv4-mapped IPv6 = address)

-IA Address option  (for IPv4-mapped IPv6 = address)

 

Is this possible?? =

 

 

To work more actively, I am going to ask you = more questions, and look forward to hearing from = you.

I will try to reply your questions as many as = I can.

 

 

Have a nice day = !!

------=_NextPart_000_0001_01C193A1.80B68EB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 2 09:22:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04503; Wed, 2 Jan 2002 09:22:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08652; Wed, 2 Jan 2002 09:18:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08587 for ; Wed, 2 Jan 2002 09:18:04 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04405 for ; Wed, 2 Jan 2002 09:18:00 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g02EI2W04816 for ; Wed, 2 Jan 2002 08:18:02 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g02EI1t10795 for ; Wed, 2 Jan 2002 08:18:01 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jan 02 08:18:00 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 08:18:00 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CCED@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Dany JUNG'" , dhcwg@ietf.org Subject: RE: [dhcwg] About draft No. 22 Date: Wed, 2 Jan 2002 08:18:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19398.48605770" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19398.48605770 Content-Type: text/plain; charset="iso-8859-1" RE Question 1, while it may not strictly be needed in the Reply, having the client's DUID may be useful for authentication purposes. RE Question 2, the Reply would have: - IA option (encapsulating the IA Address option) for "regular" addresses - DSTM Global IPv4 Address option (encapsulating an IA option, which encapsulates the IA Address Option, for the IPv4-mapped IPv6 address). - Bernie Volz -----Original Message----- From: Dany JUNG [mailto:jji21c@i2soft.net] Sent: Wednesday, January 02, 2002 1:24 AM To: dhcwg@ietf.org Subject: [dhcwg] About draft No. 22 Hi all~ While I was reading draft-22.txt, I got to have several questions. I would like to ask you all and share information as a fellow from now on. I have been an observer, although this is a great community. I would love to work more actively. 1. Why does Reply message have DUID option in this chart? B. Appearance of Options in Message Types The following table indicates with a "*" the options are allowed in each DHCP message type: DUID IA RTA ORO Pref Time Client Server DSTM DSTM Forw. Forw. Addr Tunn Solicit * * * * Advert. * * * * * * * Request * * * * Confirm * * * * Renew * * * * Rebind * * * * Decline * * * * Release * * * * Reply * * * * * * * Reconf. * * Inform. * * R-forw. * * R-repl. * * 2. What do you configure for reply message's options if you are questioned to assign IPv6 address and IPv4 address for DSTM in request message simultaneously ? Options of Reply message are as follow -IA option -IA Address option -DSTM Global IPv4 address option -IA option (for IPv4-mapped IPv6 address) -IA Address option (for IPv4-mapped IPv6 address) Is this possible?? To work more actively, I am going to ask you more questions, and look forward to hearing from you. I will try to reply your questions as many as I can. Have a nice day !! ------_=_NextPart_001_01C19398.48605770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RE=20 Question 1, while it may not strictly be needed in the Reply, having = the=20 client's DUID may be useful for authentication = purposes.
 
RE=20 Question 2, the Reply would have:
 
- IA=20 option (encapsulating the IA Address option) for "regular"=20 addresses
- DSTM=20 Global IPv4 Address option (encapsulating an IA option, which = encapsulates the=20 IA Address Option, for the IPv4-mapped IPv6 = address).

 

- Bernie Volz

-----Original Message-----
From: Dany JUNG=20 [mailto:jji21c@i2soft.net]
Sent: Wednesday, January 02, = 2002 1:24=20 AM
To: dhcwg@ietf.org
Subject: [dhcwg] About = draft No.=20 22

Hi all~

 

While I was reading draft-22.txt, I got to = have=20 several questions.

I would like to ask you all and share = information as a=20 fellow from now on.

I have been an observer, although this is a = great=20 community.

I would love to work more=20 actively.

 

1. Why does Reply message have DUID option = in this=20 chart?

 

 B.=20 Appearance of Options in Message Types

 

  =20 The following table indicates with a "*" the options are = allowed=20 in

  =20 each DHCP message=20 type:

 

 

       =20 DUID   = IA    RTA   ORO  Pref  Time Client Server = DSTM  = DSTM

           &= nbsp;           &= nbsp;           &= nbsp;        =20 Forw. =20 Forw. Addr =20 Tunn

Solicit    *     *     *    =20 *

Advert.    *     *     *          =20 *     = *           &= nbsp;    =20 *    =20 *

Request    *     *     *    =20 *

Confirm     *     *     *    =20 *

Renew      = *     *     *    =20 *

Rebind     *     *     *    =20 *

Decline    *     *     *    =20 *

Release    *     *     *    =20 *

Reply      = *     *     *          =20 *     = *           &= nbsp;    =20 *    =20 *

Reconf.    = *           &= nbsp;    =20 *

Inform.    *           &= nbsp;    =20 *

R-forw.           &= nbsp;           &= nbsp;           &= nbsp;   =20 *    =20 *

R-repl.           &= nbsp;           &= nbsp;           &= nbsp;   =20 *    =20 *

 

 

2. What do you configure for reply = message's options=20 if you are questioned to assign IPv6 address and

IPv4 address for DSTM in request message = simultaneously ?

 

 

Options of Reply message are as=20 follow

-IA option

-IA Address = option

-DSTM Global IPv4 address=20 option

-IA option (for IPv4-mapped IPv6=20 address)

-IA Address option  (for IPv4-mapped = IPv6=20 address)

 

Is this possible?? =

 

 

To work more actively, I am going to ask = you more=20 questions, and look forward to hearing from = you.

I will try to reply your questions as many = as I=20 can.

 

 

Have a nice day=20 = !!

------_=_NextPart_001_01C19398.48605770-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 2 16:40:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11339; Wed, 2 Jan 2002 16:40:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22992; Wed, 2 Jan 2002 16:34:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22964 for ; Wed, 2 Jan 2002 16:34:33 -0500 (EST) Received: from net-server.bradford-sw.com (host-216-153-209-2.choiceone.net [216.153.209.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11215 for ; Wed, 2 Jan 2002 16:34:28 -0500 (EST) Received: (qmail 22738 invoked from network); 3 Jan 2002 10:13:53 -0000 Received: from charger.bradford-sw.com (HELO milton-sw.com) (hackert@192.168.10.71) by net-server.bradford-sw.com with SMTP; 3 Jan 2002 10:13:53 -0000 Message-ID: <3C337AE8.6635B5FB@milton-sw.com> Date: Wed, 02 Jan 2002 16:26:00 -0500 From: Alan Hackert Reply-To: hackert@milton-sw.com X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] draft-ietf-dhcp-server-mib-07.txt error Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I have been writting a SMI Mib compiler and found a *problem* with the draft-ietf-dhcp-server-mib-07.txt mib. At line 566 (MacAddress ::= TEXTUAL-CONVENTION) SIZE statement is missing a right hand parenthesis. Currently: MacAddress ::= TEXTUAL-CONVENTION SYNTAX OCTET STRING (SIZE (1..16) DISPLAY-HINT "t,l,xx[:xx...]" Should be: MacAddress ::= TEXTUAL-CONVENTION SYNTAX OCTET STRING (SIZE (1..16) ) Thanks _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 2 17:28:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12193; Wed, 2 Jan 2002 17:28:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24830; Wed, 2 Jan 2002 17:24:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24805 for ; Wed, 2 Jan 2002 17:24:58 -0500 (EST) Received: from windlord.WWP.COM (mail.worldwidepackets.com [12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12162 for ; Wed, 2 Jan 2002 17:24:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 2 Jan 2002 14:25:20 -0800 Message-ID: <917063BAB0DDB043AF5FAA73C7A835D438E9C4@windlord.WWP.COM> Thread-Index: AcGT3EpMhboS0wgoSEyA9AtoLAsuVg== From: "Gopi Krishna" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA24806 Subject: [dhcwg] (no subject) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi, I have one doubt regarding the ARP check up process by the DHCP Client once it gets IP address information through DHCP ACK. I did not understand from RFC whether this can be tested for the first DHCP ACK from Server or it can be done for later RENEW/REBIND also. But In some DHCP Client implementations,I observerd that client is doing ARP Check even in RENEW also.Is it needed? Could you please clafify this. Thanks, Gopi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 3 06:39:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29275; Thu, 3 Jan 2002 06:39:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25583; Thu, 3 Jan 2002 06:38:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25556 for ; Thu, 3 Jan 2002 06:38:20 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29271 for ; Thu, 3 Jan 2002 06:38:16 -0500 (EST) Received: from f02n16e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g03BYHP150528 for ; Thu, 3 Jan 2002 22:34:17 +1100 Received: from d23m0062.in.ibm.com (d23m0062.in.ibm.com [9.184.199.181]) by f02n16e.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g03BaKZ99270 for ; Thu, 3 Jan 2002 22:36:21 +1100 To: dhcwg@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Suresh Kodati" Date: Thu, 3 Jan 2002 17:05:14 +0530 X-MIMETrack: Serialize by Router on d23m0062/23/M/IBM(Release 5.0.8 |June 18, 2001) at 03/01/2002 05:05:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [dhcwg] DHCPv6 draft No. 22 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Some comments regarding draft 22: Are there any error messaged the client can expect from server in response to inform-request?. Clients behavior after receipt of REPLY message for Inform-request message were not mentioned in section 18.1.6. Typos in section 7.1 ( DEC_MAX_RT, DEC_MAX_RC) Thanks and regards Suresh Kodati _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 3 09:28:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01926; Thu, 3 Jan 2002 09:28:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00203; Thu, 3 Jan 2002 09:28:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00182 for ; Thu, 3 Jan 2002 09:28:16 -0500 (EST) Received: from ns4.trafficnet.net ([211.101.236.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01912 for ; Thu, 3 Jan 2002 09:28:09 -0500 (EST) Received: from sendmail ([211.101.236.29]) by ns4.trafficnet.net (8.11.6/8.11.6) with SMTP id g03EVub30286 for ; Thu, 3 Jan 2002 22:31:57 +0800 Message-Id: <200201031431.g03EVub30286@ns4.trafficnet.net> From: Christine Hall To: "dhcwg@ietf.org" Date: Thu, 3 Jan 2002 22:30:24 +0800 X-Mailer: CSMTPConnection v2.17 MIME-Version: 1.0 Content-Type: multipart/related; boundary="02ee336b-b043-41a5-b472-8150c331fe85" Content-Transfer-Encoding: quoted-printable Reply-To: Christine Hall Subject: [dhcwg] WWW.DHCP.ORG Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format --02ee336b-b043-41a5-b472-8150c331fe85 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi

I visited WWW.DHCP.ORG, = and noticed that you're not listed on some search engines! I think we can = offer you a service which can help you increase traffic and the number of = visitors to your website.

I would like to introduce you to TrafficMagnet.net. We offer a unique = technology that will submit your website to over 300,000 search engines and = directories every month.

You'll be surprised by the low cost, and by how effective this website = promotion method can be.

To find out more about TrafficMagnet and the cost for submitting your = website to over 300,000 search engines and directories, visit www.TrafficMagnet.net.

I would love to hear from you.


Best Regards,

Christine Hall
Sales and Marketing
E-mail: christine@trafficmagnet.net
http://www.TrafficMagnet.net
--02ee336b-b043-41a5-b472-8150c331fe85-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 3 11:19:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05269; Thu, 3 Jan 2002 11:19:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06909; Thu, 3 Jan 2002 11:18:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06883 for ; Thu, 3 Jan 2002 11:18:53 -0500 (EST) Received: from windlord.WWP.COM (mail.worldwidepackets.com [12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05250 for ; Thu, 3 Jan 2002 11:18:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 3 Jan 2002 08:19:22 -0800 Message-ID: <917063BAB0DDB043AF5FAA73C7A835D421328F@windlord.WWP.COM> Thread-Topic: Is ARP Check Up process needed for later RENEW/REBIND states??? Thread-Index: AcGUclVCy0HpcOuPQz+cDMQsIXaOvA== From: "Gopi Krishna" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06884 Subject: [dhcwg] Is ARP Check Up process needed for later RENEW/REBIND states??? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi, I have one doubt regarding the ARP check up process by the DHCP Client once it gets IP address information through DHCP ACK. I did not understand from RFC whether this can be tested for the first DHCP ACK from Server or it can be done for later RENEW/REBIND also. But In some DHCP Client implementations,I observerd that client is doing ARP Check even in RENEW also.Is it needed? Could you please clafify this. Thanks, Gopi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 4 03:47:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29365; Fri, 4 Jan 2002 03:47:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14617; Fri, 4 Jan 2002 03:46:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14591 for ; Fri, 4 Jan 2002 03:46:20 -0500 (EST) Received: from mail.frequentis.com (213047210148.chello.at [213.47.210.148] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29356 for ; Fri, 4 Jan 2002 03:46:17 -0500 (EST) Received: from FRQVIE-EXT-MTA by mail.frequentis.com with Novell_GroupWise; Fri, 04 Jan 2002 09:45:34 +0100 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Fri, 04 Jan 2002 09:45:19 +0100 From: "Gabor Gorcsos" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_B4E9B0BE.96F79131" Subject: [dhcwg] DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_B4E9B0BE.96F79131 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit help --=_B4E9B0BE.96F79131 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit help --=_B4E9B0BE.96F79131-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 4 05:27:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00181; Fri, 4 Jan 2002 05:27:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17409; Fri, 4 Jan 2002 05:26:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17378 for ; Fri, 4 Jan 2002 05:26:01 -0500 (EST) Received: from u533-015.cradle.com ([66.52.184.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00167 for ; Fri, 4 Jan 2002 05:25:57 -0500 (EST) Received: from alka ([192.168.1.50]) by u533-015.cradle.com (8.8.8+Sun/8.8.8) with SMTP id CAA03602 for ; Fri, 4 Jan 2002 02:25:51 -0800 (PST) Message-ID: <019b01c1950b$771f8da0$3201a8c0@cradle.com> From: "Alka Mohite" To: References: <917063BAB0DDB043AF5FAA73C7A835D421328F@windlord.WWP.COM> Date: Fri, 4 Jan 2002 16:04:58 +0530 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Subject: [dhcwg] rfc 2131 confusion Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi The rfc 2131, page 23 last but one para has a very confusing statement "In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff". Just before this line, you have explained the actions for combinations of "giaddr" and "ciaddr", which contradicts with the above statements. Can anyone, please clarify. Thanks, Alka. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 4 09:14:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02914; Fri, 4 Jan 2002 09:14:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22881; Fri, 4 Jan 2002 09:13:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22855 for ; Fri, 4 Jan 2002 09:13:03 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02812 for ; Fri, 4 Jan 2002 09:13:01 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-160.cisco.com [10.82.224.160]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28055 for ; Fri, 4 Jan 2002 09:12:32 -0500 (EST) Message-Id: <4.3.2.7.2.20020104091149.038d6900@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Jan 2002 09:13:08 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Latest rev of DHCPv6 spec (resend) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I resbumitted draft-ietf-dhc-dhcpv6-22.txt to the IETF for publication on 1/2. I received an ACK that the submission was received, but I don't see that it has been published, yet. In the interim, you can obtain a copy of the new draft from http://www.dhcp.org/dhcpv6-22.txt. (Reminder!) Based on the discussion at the WG meeting in Salt Lake City, draft-ietf-dhc-dhcpv6-22.txt is ready for WG last call. I will officially start the WG last call as soon as the new draft is published; the last call will run until Friday, 1/11. Feel free to read a copy of the draft from www.dhcp.org and post your comments here... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 4 10:15:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04982; Fri, 4 Jan 2002 10:15:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24534; Fri, 4 Jan 2002 10:14:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24509 for ; Fri, 4 Jan 2002 10:14:30 -0500 (EST) Received: from net-server.bradford-sw.com (host-216-153-209-2.choiceone.net [216.153.209.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04971 for ; Fri, 4 Jan 2002 10:14:28 -0500 (EST) Received: (qmail 12548 invoked from network); 5 Jan 2002 03:53:36 -0000 Received: from charger.bradford-sw.com (HELO milton-sw.com) (hackert@192.168.10.71) by net-server.bradford-sw.com with SMTP; 5 Jan 2002 03:53:36 -0000 Message-ID: <3C35C761.3FB045DE@milton-sw.com> Date: Fri, 04 Jan 2002 10:16:49 -0500 From: Alan Hackert Reply-To: hackert@milton-sw.com X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] imports missing in draft-ietf-dhcp-server-mib-07.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The draft-ietf-dhcp-server-mib-07.txt is missing NOTIFICATION-TYPE macro from the SNMPv2-SMI import list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 4 22:47:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20132; Fri, 4 Jan 2002 22:47:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17260; Fri, 4 Jan 2002 22:46:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17231 for ; Fri, 4 Jan 2002 22:46:45 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20126 for ; Fri, 4 Jan 2002 22:46:41 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Sat, 5 Jan 2002 12:49:27 +0900 From: "yong sung Roh" To: Subject: [dhcwg] Question for draft-ietf-dhc-dhcpv6-22.txt Date: Sat, 5 Jan 2002 12:53:29 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA17232 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Dear all dhcwg members. Hi. all. Happy new year for all dhcwg members~!! While I was reading draft-22.txt, I had two questions. First : When a client requests an IPv4 address to server, DSTM Global IPv4 address option MUST be included to indicate that client is now requesting IPv4 address. But, Appendix B describes that Request, Renew, Rebind, and Reconfigure message could not include DSTM Option. If a client wants to be assigned IPv4 address, how can I notify to DHCPv6 servers? Need to add OPTION_DSTM code in ORO? If so, when a client want to extend lifetime of IPv4 address, should IAs be included without encapsulating IAs to DSTM Global IPv4 address option? Second : In IPv4 circumstance, each client have its default gateway address information. I think that default gateway address must be needed to DSTM circumstance, too. But in draft-22.txt, there is no consi- deration of IPv4 default gateway address. Does not need to be assigned to clients? If not, How can clients acquire its default gateway addre- ss information? Sorry for my poor english skili, But Please give me advices about it. Sincerely, Yong sung Roh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 5 22:09:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10341; Sat, 5 Jan 2002 22:09:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28855; Sat, 5 Jan 2002 22:06:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28830 for ; Sat, 5 Jan 2002 22:06:56 -0500 (EST) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10333 for ; Sat, 5 Jan 2002 22:06:52 -0500 (EST) Received: from todd.ucsd.edu (24-165-21-75.san.rr.com [24.165.21.75]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g0636sP20585 for ; Sat, 5 Jan 2002 19:06:54 -0800 (PST) Message-Id: <5.1.0.14.0.20020105185728.00adb778@cybermed.ucsd.edu> X-Sender: porteous@cybermed.ucsd.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Jan 2002 19:05:59 -0800 To: dhcwg@ietf.org From: Todd Porteous Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Solaris DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org A newbie to dhcp: Configuration: Solaris 8, DHCP server, subnet 255.255.0.0, default router 132.239.59.193 other routers include 132.239.59.65, 132.239.59.95 1) I am in charge of a subnet that has a number of routers I have a dhcp server on one of the routers and it assigns IPs accordingly on that router but it doesn't assign IPs across the routers. How can I have the DHCP server assign IPs across router? I would prefer to not have to have 3 or 4 dhcp server running on each router segment. 2) DHCP server assigns IP but on the client, I have to put a gateway address for acces outside my network. How can I configure server that that the client uses the servers gateway? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 5 22:45:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11519; Sat, 5 Jan 2002 22:45:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29741; Sat, 5 Jan 2002 22:43:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29712 for ; Sat, 5 Jan 2002 22:42:54 -0500 (EST) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11508 for ; Sat, 5 Jan 2002 22:42:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id TAA75381; Sat, 5 Jan 2002 19:28:20 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sat, 5 Jan 2002 19:28:19 -0800 (PST) From: Bernard Aboba To: Christian Wix cc: dhcwg@ietf.org Subject: Re: [dhcwg] Security issue In-Reply-To: <001101c17e5e$6d005b10$f7d126c0@vjk.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Is it possible to prevent a computer to get access to a network if I only know the MAC address of the network adapter? > If yes, how? Use IEEE 802.1X network port authentication and deny access to the machine. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 6 01:18:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12751; Sun, 6 Jan 2002 01:18:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11566; Sun, 6 Jan 2002 01:15:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11537 for ; Sun, 6 Jan 2002 01:15:26 -0500 (EST) Received: from servidorlotus.inar.com (217-126-14-13.uc.nombres.ttd.es [217.126.14.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12722 for ; Sun, 6 Jan 2002 01:15:19 -0500 (EST) From: fgosite@hotnail.com Message-Id: <200201060615.BAA12722@ietf.org> Received: from jsh ([61.248.232.179]) by servidorlotus.inar.com (Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) with SMTP id 41256B39.00226D08; Sun, 6 Jan 2002 07:16:05 +0100 To: dhcwg@ietf.org Content-Type: text/html;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Reply-To: fgosite@hotnail.com Date: Sun, 6 Jan 2002 15:14:04 +0900 X-Priority: 3 X-Library: Indy 8.0.25 Subject: [dhcwg] =?EUC-KR?B?W7GksO1dILGmwvrAuiDBpLq4sPjAryC758DMxq7A1LTPtNku?= Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org


안녕하십니까. 새해에는 귀하가 좋은 일만 생기시길 기원드립니다.
괜찮은 사이트를 소개하고자 메일드립니다.
요즘 많은 사이트들이 입장 또는 사이트 종료시, 기타페이지에서
성인관련/게런티를 위한 홍보팝업창 등을 몇 개씩 띄우고 있습니다.
그 외에도 각 페이지를 보면 성인용 배너들도 달아놓고 있습니다.

하지만 제가 소개하는 사이트는,
팝업 광고창이 없고, 빠른 페이지 검색과 이동이 가능한
각종 컴퓨터/인터넷 정보를 담고 있는 사이트입니다.
한눈에 분류별로 정보가 들어와서 편리합니다.
귀하의 웹서핑 능력을 '한층' 올려줄 것입니다. 모든 정보는 무료입니다.

http://FFFGO.com
http://FFFGO.wo.to
http://FFFGO.ce.ro

홈페이지 가지고 계신분은 링크교환 허용합니다.
교환은 사이트를 참고해 주십시오.

본 메일은 정보통신부 권고사항에 의거하여 제목에 [광고]라 표시된 메일입니다.
허락없이 보내어 죄송합니다. 귀하에게 한번만 발송하는 것입니다.
따라서 전혀 수신거부 하실 필요 없습니다.
문의하실 분은 메일주십시오. 읽어주셔서 감사합니다.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 6 14:15:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25618; Sun, 6 Jan 2002 14:15:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29899; Sun, 6 Jan 2002 14:13:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29872 for ; Sun, 6 Jan 2002 14:13:32 -0500 (EST) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25603 for ; Sun, 6 Jan 2002 14:13:27 -0500 (EST) Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 16NIjY-0006G9-00 for dhcwg@ietf.org; Sun, 6 Jan 2002 20:13:28 +0100 Received: from pd9e58fcd.dip.t-dialin.net ([217.229.143.205] helo=tiffy) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 16NIjY-0001xS-00 for dhcwg@ietf.org; Sun, 6 Jan 2002 20:13:28 +0100 From: "Ralf Peveling" To: Date: Sun, 6 Jan 2002 20:11:24 +0100 Message-ID: <000001c196e5$ef919fe0$3002a8c0@tiffy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C196EE.515607E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [dhcwg] interface-mtu and Windows Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C196EE.515607E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I set up a dhcp-server on a Linux-box. I set the option interface-mtu 1300. But Windows seems to ignore this option. Is there a way to tell a Windows-client to use another MTU than 1500 via dhcp? -- Ralf Peveling ralf@peveling.net http://www.peveling.net ------=_NextPart_000_0001_01C196EE.515607E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nachricht
Hello,
 
I set = up a=20 dhcp-server on a Linux-box. I set the option interface-mtu 1300. But = Windows=20 seems to ignore this option. Is there a way to tell a Windows-client to = use=20 another MTU than 1500 via dhcp?
 
--
Ralf Peveling
ralf@peveling.net
http://www.peveling.net
 
------=_NextPart_000_0001_01C196EE.515607E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 13:19:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23347; Mon, 7 Jan 2002 13:19:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16589; Mon, 7 Jan 2002 13:16:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16566 for ; Mon, 7 Jan 2002 13:16:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23288 for ; Mon, 7 Jan 2002 13:16:51 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-97.cisco.com [161.44.149.97]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA18950 for ; Mon, 7 Jan 2002 13:16:22 -0500 (EST) Message-Id: <4.3.2.7.2.20020107131453.03655360@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Jan 2002 13:16:58 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Minutes from meeting in SLC, 12/10 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here are draft minutes from the WG meeting in SLC. Please review and reply with comments by Wednesday, 1/12. Thanks... - Ralph ===== DHC WG meeting, Salt Lake City 12/10/2001 These minutes were prepared by Ralph Droms, based on notes from Ted Lemon and Stuart Cheshire. DHC WG activities update, Ralph Droms ------------------------------------- The DHCP FORCERENEW message, for server-initiated client configuration, has been published as RFC 3203. The DHCP Failover Protocol spec , and Subnet Selection sub-option for the Relay Agent Information Option spec are both ready for IETF last call. Encoding Long DHCP Options and The Classless Static Route Option for DHCP are with the Internet Area Directors for submission to the IESG. The DHCP Domain Search Option is ready for publication, awaiting publication of Encoding Long DHCP Options to resolve a normative reference. Thomas Narten pointed out that there is a serious security problem with configuration of the domain search list: an attacker might configure a host with a domain search list that can cause names to be resolved silently to unexpected targets; e.g., a reference to "my-webserver" would be resolved as "my-webserver.attackersite.com". Narten noted that DNSSEC can't solve this problem, as the DNS name (which points unexpectedly at the attacker host) is resolved correctly. VPN Identifier sub-option for the Relay Agent Information Option , Kim Kinnear ---------------------------------------------------------------- Draft has no substantive changes; updates include an improved IANA considerations section and later expiry times. WG requested no additional changes prior to WG last call. DHCP VPN Information option , Richard Johnson --------------------------------------------------------------- This option is essentially identical to VPN Identifier sub-option for the Relay Agent Information Option. WG requested no additional changes prior to WG last call. DHCP Lease Query , Kim Kinnear ---------------------------------------------------------------- -03 draft was submitted but not published before IETF 52 due to mailer problems. The current draft needs to be revised slightly to support multiple queries in a single option, because this behavior is implied by Encoding Long DHCP Options . -04 draft should be ready for WG last call. Kinnear reported that there is a need to move quickly on this draft, as there are implementors waiting to find out the TBD values before completing implementations. Dynamic Host Configuration Protocol (DHCP) Server MIB , Barr Hibbs ----------------------------------------------------- The latest draft includes minor revisions. Security has been made easier through the removal of ability to send some MIB elements. Many other simplifications, removing and simplifying variables deemed to be of limited usefulness. Next rev will be ready for WG last call. DHCP Load Balancing Algorithm for IPv6, Bernie Volz -------------------------------------------------- Volz proposed to extend DHCP load balancing to IPv6. Two questions: what should be used as the hash key and how should the servers behave when the client is not in the server's hash bucket? Narten said that the IESG was unhappy with the DHCPv4 load balancing behavior, in which a server drops requests not in its bucket, because there is no recovery mechanism in response to a server failure. Volz suggested that DHCPv6 load balancing set the server preference; Ted Lemon replied that the result would not be "load balancing". Vloz to take the discussion to the mailing list. IPv4 Address Conflict Detection , Stuart Cheshire ----------------------------------------------------------------- Cheshire's draft captures, precisely defines and clarifies address conflict detection in IPv4. This mechanism is used, for example, in the DHCP spec. Cheshire's goal is to document IPv4 address detection in one place to be referenced by other specs. Kim Kinnear asked if this draft should be a DHC WG draft? Cheshire wondered if DHC is the right place, as other WG specs will reference his doc. Narten opined that DHC WG would be OK, as this WG has significant experience with the problem. Narten suggested that the document carefully document motivation for details such as timeouts, and document exceptions to SHOULDs and MUSTs. Qualifying the Root Path Option for iSCSI Boot , Prasenjit Sarkar ------------------------------------------------------ Sarkar's draft describes a way to use the root-path option for passing a text string containing the IP address and target ID for iSCSI boot device. WG consensus was that proposed encoding fits within current definition of root-path option, so the encoding can be defined in the IPS WG document about iSCSI boot and no separate DHC WG document is required. 802.1X Credentials Sub-option for the DHCP Relay Agent Information Option , John Schnizlein, Ralph Droms ------------------------------------------------------------------ Schnizlein and Droms have defined a new agent information suboption that carries 802.1x authentication credentials from a relay agent to a DHCP server. Once the 802.1x authentication has been completed and the port turned on, the relay agent can send the 802.1x authentication credentials to the DHCP server, which the DHCP server can then use, for example, to identify the DHCP client. WG agreed to take this spec on as a WG item. Authors to update draft, changing "credentials" to "identity information" and other changes based on WG input. Use of the Host Name option for inferred DNS updates by DHCP servers, Carl Smith, Ted Lemon --------------------------------------------------------------------- Smith and Lemon proposed writing a document that specifies the use of the Host Name option for DNS updates by DHCP servers. The purpose of the document would be to capture current practice in a clarification and precise specification. The WG agreed to take this specification as a WG work item. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) , Jim Bound, Ralph Droms ------------------------------------------------------ WG discussed the -21 draft. Authors' plan is to revise spec based on input from WG and publish -22 draft. -22 draft will then be submitted for WG last call. Narten pointed out that 3GPP spec has normative reference to DHCPv6 and needs DHCPv6 spec by March, 2002. Primary change in -21 draft is modification to text on identity associations. New text, with scoped options for addresses and identity associations, was discussed and accepted by the WG. The authors asked for help with temporary addresses. Consensus from WG was to proceed with as simple a mechanism as possible: addresses are simply labelled as "temporary", with no additional statement in DHCP spec about lifetimes, extending lifetimes, etc.; client can request temporary addresses; server can assign temporary addresses. Reconfigure now has a problem because of Inform message: currently, only a Request can satisfy an outstanding Reconfigure message from the server. Inform should also satisfy Reconfigure. Lemon pointed out that Inform can satisfy Reconfigure only if server hasn't assigned any addresses to the client; authors will revise text to reflect this observation. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 15:03:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26471; Mon, 7 Jan 2002 15:03:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19733; Mon, 7 Jan 2002 15:02:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19709 for ; Mon, 7 Jan 2002 15:02:45 -0500 (EST) Received: from c001.iad.cp.net (c001-h000.c001.iad.cp.net [209.228.6.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26444 for ; Mon, 7 Jan 2002 15:02:42 -0500 (EST) Received: (cpmta 12206 invoked from network); 7 Jan 2002 15:02:13 -0500 Received: from 4.36.57.222 (HELO STEVEPC) by smtp.relicore.com (209.228.6.114) with SMTP; 7 Jan 2002 15:02:13 -0500 X-Sent: 7 Jan 2002 20:02:13 GMT From: "Steve Gonczi" To: Subject: RE: [dhcwg] Minutes from meeting in SLC, 12/10 Date: Mon, 7 Jan 2002 14:57:53 -0500 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <4.3.2.7.2.20020107131453.03655360@funnel.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Greetings, I have just read the minutes of the last WG meeting. I am responding to the following: > (Tom) Narten said that >the IESG was unhappy with the DHCPv4 load balancing behavior, in which >a server drops requests not in its bucket, because there is no >recovery mechanism in response to a server failure. I believe RFC 3074 provides an option to deal with this... Section 5.3 (Delayed Service parameter) Happy New Year to all! /sG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 16:35:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28585; Mon, 7 Jan 2002 16:35:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22323; Mon, 7 Jan 2002 16:34:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22299 for ; Mon, 7 Jan 2002 16:34:03 -0500 (EST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28571 for ; Mon, 7 Jan 2002 16:34:01 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g07LX5a01736; Mon, 7 Jan 2002 16:33:05 -0500 Message-Id: <200201072133.g07LX5a01736@cichlid.adsl.duke.edu> To: "Steve Gonczi" cc: dhcwg@ietf.org Subject: Re: [dhcwg] Minutes from meeting in SLC, 12/10 In-Reply-To: Message from "Steve Gonczi" of "Mon, 07 Jan 2002 14:57:53 EST." Date: Mon, 07 Jan 2002 16:33:05 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > > (Tom) Narten said that > >the IESG was unhappy with the DHCPv4 load balancing behavior, in which > >a server drops requests not in its bucket, because there is no > >recovery mechanism in response to a server failure. > I believe RFC 3074 provides an option to deal with this... > Section 5.3 (Delayed Service parameter) But it is not required so you end up with different products doing different things... Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 18:05:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00352; Mon, 7 Jan 2002 18:05:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25625; Mon, 7 Jan 2002 18:04:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25602 for ; Mon, 7 Jan 2002 18:04:42 -0500 (EST) Received: from c001.iad.cp.net (c001-h016.c001.iad.cp.net [209.228.6.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00343 for ; Mon, 7 Jan 2002 18:04:40 -0500 (EST) Received: (cpmta 22398 invoked from network); 7 Jan 2002 18:04:07 -0500 Received: from 4.36.57.222 (HELO STEVEPC) by smtp.relicore.com (209.228.6.90) with SMTP; 7 Jan 2002 18:04:07 -0500 X-Sent: 7 Jan 2002 23:04:07 GMT From: "Steve Gonczi" To: "Thomas Narten" Cc: Subject: RE: [dhcwg] Minutes from meeting in SLC, 12/10 Date: Mon, 7 Jan 2002 17:59:47 -0500 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <200201072133.g07LX5a01736@cichlid.adsl.duke.edu> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I see your point. As I recall it did not seem reasonable to mandate site admin policy. There was a discussion on the WG list at the time, and we ended up making the _presence_ of this knob optional. Perhaps, we should mandate the _support_ of this option in implementations, and just allow it to be turned off. >But it is not required so you end up with different products doing >different things... /sG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 21:17:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03172; Mon, 7 Jan 2002 21:17:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01399; Mon, 7 Jan 2002 21:16:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01377 for ; Mon, 7 Jan 2002 21:16:49 -0500 (EST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03158 for ; Mon, 7 Jan 2002 21:16:46 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g082FnQ02950; Mon, 7 Jan 2002 21:15:49 -0500 Message-Id: <200201080215.g082FnQ02950@cichlid.adsl.duke.edu> To: "Steve Gonczi" cc: dhcwg@ietf.org Subject: Re: [dhcwg] Minutes from meeting in SLC, 12/10 In-Reply-To: Message from "Steve Gonczi" of "Mon, 07 Jan 2002 17:59:47 EST." Date: Mon, 07 Jan 2002 21:15:49 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > As I recall it did not seem reasonable to mandate > site admin policy. There was a discussion on the WG list > at the time, and we ended up making the _presence_ of this > knob optional. Right. If the implementation is optional, the operator may not have the option to enable, i.e., if the products didn't implement the feature. > Perhaps, we should mandate the _support_ of this option > in implementations, and just allow it to be turned off. That might have been better. And would it have caused a lot of hardship to implement? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 21:42:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04412; Mon, 7 Jan 2002 21:42:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02131; Mon, 7 Jan 2002 21:41:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02109 for ; Mon, 7 Jan 2002 21:41:33 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04409 for ; Mon, 7 Jan 2002 21:41:30 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g082fWW09823 for ; Mon, 7 Jan 2002 20:41:32 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g082fW829120 for ; Mon, 7 Jan 2002 20:41:32 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 07 20:41:31 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 20:41:31 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD28@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Steve Gonczi Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Minutes from meeting in SLC, 12/10 Date: Mon, 7 Jan 2002 20:41:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C197ED.FA551D90" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C197ED.FA551D90 Content-Type: text/plain; charset="iso-8859-1" It is very simple to implement. The check itself is basically one line of code: if (secs > threshold) The configuration of the parameter is likely the more complex! I will consider this change in the revision of RFC 3074 I'm planning - primarily to incorporate DHCPv6 (DUID). - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Monday, January 07, 2002 9:16 PM To: Steve Gonczi Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Minutes from meeting in SLC, 12/10 > As I recall it did not seem reasonable to mandate > site admin policy. There was a discussion on the WG list > at the time, and we ended up making the _presence_ of this > knob optional. Right. If the implementation is optional, the operator may not have the option to enable, i.e., if the products didn't implement the feature. > Perhaps, we should mandate the _support_ of this option > in implementations, and just allow it to be turned off. That might have been better. And would it have caused a lot of hardship to implement? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C197ED.FA551D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Minutes from meeting in SLC, 12/10

It is very simple to implement. The check itself is = basically one line of code:
        if (secs = > threshold) <respond to client>

The configuration of the parameter is likely the more = complex!

I will consider this change in the revision of RFC = 3074 I'm planning - primarily to incorporate DHCPv6 (DUID).

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Monday, January 07, 2002 9:16 PM
To: Steve Gonczi
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Minutes from meeting in SLC, = 12/10


> As I recall it did not seem reasonable to = mandate
> site admin policy. There was a discussion on = the WG list
> at the time, and we ended up making the = _presence_ of this
> knob optional.

Right. If the implementation is optional, the = operator may not have
the option to enable, i.e., if the products didn't = implement the
feature.

> Perhaps, we should mandate the _support_ of this = option
> in implementations, and just allow it to be = turned off.

That might have been better. And would it have caused = a lot of
hardship to implement?

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C197ED.FA551D90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 7 22:44:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06080; Mon, 7 Jan 2002 22:44:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03538; Mon, 7 Jan 2002 22:43:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03517 for ; Mon, 7 Jan 2002 22:43:51 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06077 for ; Mon, 7 Jan 2002 22:43:47 -0500 (EST) Received: from green.bisbee.fugue.com (tnt14b-67.focal-chi.corecomm.net [216.214.204.67]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g083fOS12248; Mon, 7 Jan 2002 19:41:24 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g083iDV00828; Mon, 7 Jan 2002 22:44:13 -0500 (EST) Date: Mon, 7 Jan 2002 22:44:12 -0500 Subject: Re: [dhcwg] Minutes from meeting in SLC, 12/10 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: dhcwg@ietf.org, Steve Gonczi , "'Thomas Narten'" To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD28@EAMBUNT705> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit My only recollection as to why there might have been a reason to make this optional was that it was unknown at the time whether all clients actually put real values in the secs field of the DHCP packet. I think it's fine to make support for this in agents that implement load balancing mandatory anyway, though - all of the major clients of which I am aware do correctly support the secs field. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 08:47:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20773; Tue, 8 Jan 2002 08:47:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29106; Tue, 8 Jan 2002 08:42:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29089 for ; Tue, 8 Jan 2002 08:42:52 -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 IAA20435; Tue, 8 Jan 2002 08:42:51 -0500 (EST) Message-Id: <200201081342.IAA20435@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Jan 2002 08:42:51 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-22.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --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-22.txt Pages : 82 Date : 07-Jan-02 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. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' [13], and can be used separately or concurrently with the latter to obtain configuration parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-22.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-22.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-22.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: <20020107134955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107134955.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 10:52:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26500; Tue, 8 Jan 2002 10:52:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04734; Tue, 8 Jan 2002 10:50:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04667 for ; Tue, 8 Jan 2002 10:50:32 -0500 (EST) Received: from bsd.totcon.com (bsd.totcon.com [209.26.173.11] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26397 for ; Tue, 8 Jan 2002 10:50:29 -0500 (EST) Received: from aol.com (unknown [209.26.176.161]) by bsd.totcon.com (Postfix) with SMTP id BD07C4756F4 for ; Tue, 8 Jan 2002 10:50:10 -0500 (EST) From: "Maxine Turner" <_jturner@totcon.com> To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="====_ABC1234567890DEF_====" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 Message-Id: <20020108155010.BD07C4756F4@bsd.totcon.com> Date: Tue, 8 Jan 2002 10:50:10 -0500 (EST) Subject: [dhcwg] Re: Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --====_ABC1234567890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC0987654321DEF_====" --====_ABC0987654321DEF_==== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --====_ABC0987654321DEF_====-- --====_ABC1234567890DEF_==== Content-Type: audio/x-wav; name="New_Napster_Site.MP3.pif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAoxs1SbKejAWynowFsp6MBF7uvAWinowHvu60BbqejAYS4qQF2p6MBhLin AW6nowEOuLABZaejAWynogHyp6MBhLioAWCnowHUoaUBbaejAVJpY2hsp6MBAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUEUAAEwBAwCoIP47AAAAAAAAAADgAA8BCwEGAABwAAAAEAAAANAAAEBHAQAA 4AAAAFABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQ AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkUAEAMAEAAABQAQBkAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAEAAAAAAAAAAEAAAA AAAAAAAAAAAAAACAAADgAAAAAAAAAAAAcAAAAOAAAABqAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5y c3JjAAAAABAAAABQAQAAAgAAAG4AAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAkCCN1hYc1ltHkUdCgBADdnAAAAEAEAJgEAve3/ //9Vi+wPvkUIi8iD4APB+QLB4ASKiWiiQACITQgX3bH//00Mi9GD4Q/B+gQLwsHhAoqAGUUJMRDB Ztvbi9AWBgvKNj8wHB1ht9tNCh8Li1Bdw1nGMhdLth89XVpiWnYoO3uKBI0JCkQKPXH9Yc8dCDZU MFGDfQwB3ZtmuxD8PQP9/v89dQ4eirbf3f8AUOgBAACbWcnDIwJ1EhNIARZR7MjNxxdWWevlA3wY AlEbR27tP9f+//+DxAw1YvzJUVO/ffv/i10MVlcz9jP/hdt+WxcQagOJHI1DAjPS2Hdf+Fn38Yld H/jB5wJH/3UQA8Zey/Zv28wg+KoMikX6iGUNCA77vdvebgUPjRFqBFAl/CI/6oNt9v/2ti2DRwSD xgbEFDvzfL2Lx19eW3T+v739ikQkBDzFAwQDCsiA4XCA+WB8AyxHw/+XptkHQEEwBATDPCsPlcCD wBd+c78+pYpNbMjRwOACwGcKwnm7Ff6LVRjA4QSIx62K0BECCsoJX/htHBwGCkUUiG5NIIgBP7C2 bbaMCAGkBwygCiLLYO4QugoUEHXNdtm+FP1QA/7/xBTt9mDOJzVA1bBAxCw4Qltoy9t0OAQMdDMQ GxIYl63Ntn//agGICOsfEBQODASt0P3C/ohtdQRqAusL/U0N+C+02wJY9jPAA2X/OXwkDH48i+3v /l8DCFNWav5bjXACK9gNGAPHUIpGAQMofOi6Bgb/A/5oAgw9Cm9vWCb4P40EMzslFHzUQT+42xtG w1aLdEZW/wRr8FlQvg3/cwrIAp+AJDAA4F7DHQiz79tFKxBWIRTKLyH7zfDDEF4ggewYzvEIiU38 UMnf+G13agDvaAIRgP8VAKCRhcAPhXb78tunAA5WV74UwI196KUr+McCDR0X3AA1KIXoTaUw9MzW bXcD6GalPlA/pDskW9i4Fes9dWSE9ApeKbfl1j1oEENQHQyhWRxZdGyzvfcIgKQFGHU0GIC9Dzs2 dnZ0KDFQv0AG/Iuiezf2fYkBjY0XURH2xbAB6ws9uW8XJjJiwgSsi/FoZGkP273dIgMthIMoaDAN i84PGGpw7PexEE/HBCQgkIkGTFlZ4Yb5zTM6gz4AdQWA/zZfW/ruDRtYi8GDIAA4Abq6f/h3dAeA QAJZw8gPt0gMUQQK3BeeeQgD8/80jaxfdnN76woGA0AEUQ+FlGg4wQTfZha6WSQIFMMkRAT9W5va i0xIhf8rH/8CdA5mixA23v6/AjQBZjvWdw9yEkdAQBUIcuVDXwzfuNCkpljrEsj/6/PAf7t1FBRH V191GgNBDgPwv+h9+0vbAwCoxrqL32o89/MJZolRDpbbir0N9/dfEg7wJxe6Xyu7BUUYHiKL9yQM Q36fa/YjGRYfQQrI2O10QgoDX1cfFOl0y8gI914+CINTx1ttDLSKadJtHgOkLb19ew5r0h4HZgNB BgPwdFsRX7bpfrsfUQI7wivHdBoDEg6Dsn777e50CQgFah/YD2oe6/nmZjkBD5SF/9+a/Bwr3jvD cx1mg/oMdQtm/xDt7e7tx0ECXOsFQnMCZitUBuusCm1zRtdxBlld0AAzyUK9gRdofU2AQO/OFBFB O7vdCm8/iJQFdgByAhxAPSQd+63wct05tVcyyYqCJpwV7/f/+x+NsgwC2ALLQg+2+YqfDYH6L3dr 99+NvwuIHqJC8AYHcrslQAl9xzpbAAZB2/4FElPc3u+3OQ0HipExABUfEgVBrc/v85iNgAWImVuI wi+2e+/CAoEKWSjAih7OwUuv4YPsDN5oflxoRPDL5XL7LvR6A/Vy9h33pfh9XC6X8vmj+sn7sZcI 1wI/NpFqCKIF/twIPkt/YwN5MzZGXzv3diO9/A42KH1H/02gH+H2b2p3JQaAMgdeiAQ5Rzv+cufK RmpqLndyyqGzIL/BzWYFHGoWmRb5i/LB5u7HR/oD/7YIxWcGzYs9zLu4DyHbGGOmU+HXIQzBbWWy FjiRKGOvXHOrPAQEH/z7AQpyv84Gegz/u0Ieu93cHVxufRVaaAimib0M4N0Dl55RQCrsDADkVg1Q Yz1rtU0iwTVUCF1dBVO7exEOU16LT+zUtnMbXchqYAFhFksz8SHd1t0UXoP4/1Z1YQgO7A/yCCTG 9kYDD3QqGhAddmBDFPCRXmCiHLuSEADVEAZKuXWg1USAMyDQ9P3tycCAZ1UH8YsYGOvu5428BYuF +AXB6BDZlmDm1mSM1Ng0AP47XXPuvzKujbQFBBN1BGLD7gWzgUujjJvbD4OTB6M0O3s6MFYxefG5 eINSpEgKiigF4AilL0n5D3VuHmyKJvZyK+xzRolTMPD5RlBWOTcTQ3hXUHzoYHwpZreSiWb+kydz FylopQgYaUTyE0J7qxUcJAt1+OkPCRjykIUrEBA8M5zd8E+ruOCTEDwffbhZMLyDZfwAIPzkiWXw thkeaBzseT8hxewXoYGfYSqMCITpN8hbQOBW8EYEfx3oQesGBiIOiR9bA9OTHLgYGkYVTPTQ0blv gmSJDQAAiQgGQJMbFDjb7YzooDwMXth1K1lqICRQxkJtBs5WCU1avb8G3w08QFEqCZ1eUHYD7a9K uV2DZtcQw7j06mDP3R1RGol18FzuYMx9zTGDCUI1Y5+euWBOOsn1IEHwnOTIkZsG9Ij4dPxokSO3 buAsgAbkAegChFuJzewDM9unbzdWGDEYiULRHThp9OC3uxB+EEOD04P7BHzdTCB2W9rni/PJAtA1 8C/FJw3vT41ECAHfDEQ14CycxthO69TVVEIzREs0cN3/NTSjDtqsZjM4PLAk0RFGn87WeHU8wHVU XjnXY+NqRBuskp9RL5b70SX9xqxEyOAxXnOtuUBZJrUqDgBz3azNTDYuYTwhKFywSqY4bUE8P9+v LVvjoFCgf/xo5OzwGesIggrDDTJoP8VYBCteH6v8731um+Yq6zwNENkIXoRZshhIm0WdzWzLxghM ZgxITUiGwWaSkQwnSRsvsWyH3Fk7x2gFLfb2h7isjU34UQP8UVeTBaEDY91I8VKNMlFvfRDqbgaa 9gUw3CB2NhO3RkBR6kACBuhoaMb5hfSbm1l2hN53KkW+05pXVtGNNHQok5EfGTbCCes3WUBCJiNQ NCs5WlZWDj0QBnMaRRQgXl9EMM6Y7xdXCtGMJIyA9s0Nk3TMgqYNKPi/mHBZe82kgmz0A+PIZjq0 VHRSPObHyXgdOVChhlBQGRtLmv28YyBJpYTxHP1XQwKMMMhgwgAA8gKS9GKH/KcUErLZrROOAfZ1 URnc7za15ADpPT4ndia+QlinZB+aNh0VcTrWVKHW3Tslct/Lsa7XV4rk+I4wAVP83z0b1Mdop4vY hduJXfwPhNUAPHHD3Ys1ZBM09MZS1g9v92sJB4v4CdTGK6HWB9sGCoO8O8Yylx3Ssz3b3geP/kKH avOx1tna1zGU0GsHhGwNuyh0/9NvaNj0iBFsyfQMhJuX20m0dSkcYKA7hdh0G6ln297/tQdkARZc xusfZrZCeQtYcv9V+LFYkd7rlKhNivkMmm7T9AUdZf8D9/4hAsFq7iAyzyZOhrEs2+AC2NzUZOdm LP4gaDTIq1yLPVgFXCy0AnUE8IeBpxH4bBdU2FPXarLZtjMDlhtTqFbdUN/QluBDHjjROnwejUwG An9hof8kMIuLffiKDDcYv+222z6WCIsZSB154g4enmpiULtrkAsqXP/q12aBvQ89mrj0BDG7qgdh DSypwQ2/M7gyyLvAd4PhAQfH3NssdmYxFx0ai716M5RsIdsbAhcRBMmUTMkIECDLyGAPZiPLcYsz hWxmc5teozIMCmK34Zhu5i5dozYPKRZ2Tw2PGw+6o6ARDWl2j18I8EKNBDeW+IkEjeMkmwCFjSKY I47CCw39/yuNfAdCi1pgtmNRcr5ZfkoI3Uu2vCC/4kJZ4izDs8BXloQwzxi0bRZsSCkMSoI8RjZ3 boDi5DoPhuVkkpFJiueOgckWZOZ/bkGDHHLYEnLpoTX73w4Ev0Ajw2Y9gAB1GDXYM6CLrSdXF+s7 EbuvhbG2ZiRXM4C76wZilixlw3YO26SnZ44IX1dZl2YdMskh62rsoSBjk82SD+2adD+4sZZqAqPi DUWYGe4gt7ad6g2oGA8U72azi8VWeAQOxAtaAifpxA1yx0AkyD5NIggDQHTvwgOmYbhOpBC7epW2 A/ABE1lwpvVfs86x15+zdBloDMjTL+iKpFYGYdBT8rP+Tbor/CVbaOjHyhzpDL/QB6Msewy4OO83 ioyNoBkI0aMo26/9dgg5DSh0HQcjdBUPCL2A+z8NO8F0CcYFPBNPB4AlMGv24QgCIdC1RzHykOyg +aZQuxCG8OwBFVNQqQo07P7r1xnsdWtomIxqbht8NrNt7dUV6AvcCOQTT3KwjZTHWaNE3sbgAgY3 fJUDWuhDX70vMdQ7j+RTnSz0TqEmN0hTQ6PDrm5saIwm+AEjZ18h4V/QDHTobjgjJ2jkGzlN0Iws m9loLAjoI+RfXZoL/xoDwRIDJbjIUaHrwekKjVGP44twhE494H34vh7yyRYLBGP4Oxw05FzsBiAT IhWSEHj2kp1wHRA3ix3SXBj2RCMRDPpMbKz7MNNPRcA4bG/AJS+bPTULcSo4IP7Gy5g0RHMkj9kD k82FuTz/BO9973b24xi+7Iv8GqUAUKVU5Jd8vu4sTPTuEL7k7uscJeRMqi4QaTTEk5GtIFZoV1b8 4jMdJPRAZlEg/7mKXOitBKKjBq5ZoCT/JBMJoJwwNuKAfctKdFXQ3fTNRvQgWfZFuQJP+HUbrGvC sSf+vSUR/vzi24F9MP1Z81lpAG3slzC2O33UdG5cA1D/CsKJ5C02UQ41WYQXYglNoU5jssxQHoLw dATKyI2U/G+DDmkgGGABk4N/y0o/hXRV6IhFnDWxu3194DyJdnYKFCOvguvbJ9SqeoQLBHRTHtgJ y7btHnZKkvf1RHha7s8u3lAQKgS2fQ2hOjMIdvvBOwVrdhIb91Amt2crG1Iu+lvY2FLcFCUH9tl2 PGEQdClVPF3r5Th8CfvViQUMFkp8toJE3Nw53JZRLcZYGEEBSKkQLBdYmkCJ6WIWayg8oBTNLFGn oAh0EsAIFwj0kkMUAXU3BeC9Ohz4oF4pcHlImdtsdBP8AXDQsKJOoAPE7Lms6/gmQQleq4RUCRKY VoJkRelpPApAJrCaAug74tC8OBBZvrjI1o79OzCUahLzpaS+rAz0pQoYdtsOz2S98cTYHL5YGzvZ 2DTof2alr5TiA+3u+H9N5g+vwYP4FaNQ8SgM0egLd/n/YQyKDXGUGxhFWbtQyFi32Q5tWUh0RBxT HSvb/Q1ZBxuuWRZZVhdpNvbBv0SeVwtWBgq3wl2jiipmaj9ZsapN/dvady+IlUwF86tmq6oVFFkV shFkpP7+x+hWjsADGOBZ7e8AGTcI8EYMdEgLAZakg348LUvSDMj+/jiq3Bo2aTCrVCGQoPjHvuPN O/h0c4scg+AQPBB1Sn3bZzZeVOKILTgXJVvBGvYQAGIXZAicTTgzDFMkDFZZGmSbcyBXEIw1SKY7 lwqIRMPeQSd2oZigqNZpyYgT8ft9gw/Bo0zxEjkFB3f22sOICyUIlBBcCyLPEx4TdT9i2fzYHCFC cwUQZI7Z+2SEC/nY+9mk2D0GbTdVNdyEhL+4xXe3Ae/PR1PWGjgRUA/mFoZJ/e4WmPSb0CDJgAC/ BBcgstnAKZj58MvsZoZabvNhRkw29hD7Tvf7IORQEH72Ei/QFwRT8wGNhceFWB8z0mzm/9wJXNRg NCPNSMxkuGisSDPSjGykcJSMNCPNdIx4hHwcOfbTfEWAdAaEXIhUkSNHjoxMkESUQDly5MjUONgw 3CjgJEc+jxzkIJj8ypzYoLTkyJEjpJiobKxEHPk8crAgtPzJuNy8vJEjR47AlMR4yEzACPHIzDDQ FMkZeFM0mMI2HWf38aMli9Zo6ikTlIFWMt4a3gganc3A0l1yCB/EuyW3lDo32P5lH387OKxmEpgc CIYP5dIDe0EW+Ci1g919IG9/lzlehCKE0AA4fYTjRlM817t9fQd0QVfZXtYw4lAkCienmNmko/3g Dv90gGr7IjWHLYx7KgHgxoc0hwwC1A//tD692Isuy/bw4EuWSsY78BSi7ACbna7nHGUl/Hub7fT2 5PwwYHM0/wX4BThbP5tQgz0VdQcNUCfLEkFwLwyMhe896ZmXEONN/O/nJax4oIhZW7uDdtAG9DMX V1b6hsMWfGogagMGaC+dWI3REnT8ULAedcFy4YP7x13w9pBTly6IbLqsouSB/2/B9xNfD4LYHVaw g+9kBU20aCWDPqjCdG3jUwP0kzakQWT7bcogsCUEUF2gbnT/dPKMdnu/AMy4fWJ1avS6EAF0EQQe vxIFeggYdUtwrJroAIf5lDWK//Zb3CM8Ink8J3QlO7tzIIP5f3MbFf4b9TwgdBToiAQRQYA8HkA3 N2r3szb4RuvQ9IAknQFGCm/Zdi5ykG/4BhQHZIGn6KacOvQZpDFZ8EWQ1vYguQAcZG9LgAjMBwLg qOCnguC+WMkl4IP0Sg4ZSODgQQ5k5OD8/NUHDnx9oK2siIUEGhEwOZzFgNxbqhECMySyG99bcoMf HMwRUyDA/segtR0IRoP+EHzP6w0amVuY4lkPUZABcL/gvXItXKFrJGhkTLslLly71Yulhfb9aIV0 LcKvqRseas6eWCZqMkW/myLEU8/nZoE9IgQxdoAR4HRSVltZm0GvKEFLf2QN9mBQczhsoWbHBTe4 7JF7aIoGelpE2YZ0zzbriXYAFlQO22w02zJ+KG5XL2zZjHl1RhgzO/XClttTRVajJD9i5S40TWhq gbxLPl2suxCKBO8wtUOeeiS+wjTvvrtHxok1qBq+4uVUoAqJHaTxl0HAFZ8HQHYlsR+CS6SLx+4P vq8pfIvY/4vKweED0+Uz3UcmS1ly2/ds3TduN/8H0RfGBaxAAwat+7//nK7rGYvDiB0YwegIwesQ ohx5C/7aEBuNRCSGAQEAh+B84ZzXXVuBxKL3dXDAU7t8rls9m8MIzaX0hLhX6GjyGrhNitSFhf99 k25bDYkUq0S2ORV1tfT+NHY6od2zEK2KV4o3tgICpTKkB4fb5N7u0sgZiw0lH8BCOzmUTj4ecsZW PVdXoLcELxKLGpw1L4TZh6WpV7JoaAujAg0E5FdUXkBEyHTPpF/LtAbfEaoQg4gDBRxZswN8Gxqo cQVFGRH+NWaRrB9WA8hRwIOaImc0ASRepJduAS+LdXFGAu9GCNsbshV8ABQDTu+G14AEXxR2MAhR Ic98H5D+BGh0zNxkKGazSUdaAEkZ5LBkxxFobCkh/gDHQoZoTDiyALScBAikAf35QnynMeOGdDeA PXQuuJxwzSrUFokGXMxz62wHO11coyzjY5no2zsSG8D32BFxuHL0YOygRQBkXH4iMg60hPD3JiFL JcfaYVBXG7zkYG1og+sycOg4LAjSdRmY+LRoY9AzQS7pHFc7QIOCOVs+G4ZgNsu1TTezvhzGsmg4 iTY733Ywu2xsANM0AoYC+4oCYpxxhnrAiCqU2cVvzBl904gGctBoJYmH1aPzDQgTpQeLr4PWS1k7 EAKV0vXkS3Ib/CflBxfMm+0Be/B1HRPGO8cnvYtAVqgvEJL/MOsGCghyxTO6V9wJZqEuO9Zw9OQE VBTAZkaBaBVg2pJMw+C6Jwa6+3ZGV1vmzk4ToAActHdkHPY5zFhHHQAkzbMHSFYtBDSwnX1BiPoD Pa4QUPUGBoMz9B4Rs2awGkCfED0Ud4POoleQKzqENRF1deSwjKjLBmbwhS1nnStQt/DDvQ3JKXma BvDMdgAy2MEjj6ncSh6FTCHwBQHIhLzMBcwrGQo5dwVGztk5ksgiG8CBHFksX6QMJYdCXtIEoQTG oEcyvH0ENGSGKWYCtAhGtYW5JROsrr+BHIG5Qr0UJmA7a1cIH6shQaVg1aTMCtsTzZ6tFRWVjIFt oGm6tzX3dHqZumij3DVhdpcPYExo3jRggxMNKv9cxNabnaxNurGwO1cSry8sEiehZOKvZANosjYr J7WuxWKzEzl718iCL/Vbw3fBWDvYdjE29IoMP9m//RCA+Q10BQQKdRyKTBD+DQ6AfBD/Cf/W2i6N EkhwAX9AO8Nyz1JoCeQUwQJJM+AaG6Ejixg3p9hS9rEjizU783LdwyywgTKcNYs1Achg/4QBu0oO hU6hAX0jHAAymKR8LRFIYoHIJh5gJcZA2MaOQOJRyq1Ag8OiBRXIbsjfZ5PqlE8jD/SadDGQ7uO0 0dmTLicUpaUWpShhp2Imzay42nD0NqJX6HTR/hJ07hEcK9hXUwPBk2IqoxgVQxi4dwHLVkB99HQJ zYRbnBUvffd0CFENOAEfoqGw8TRajgw9ijP1IxlVIGL0DMYGAVqvKNLvK/gjo7KhYOcIRhq2YAcH pAxX6EVfFmjaNUDVXimqKUo9JJu7ONiqVUQHqRdXK2R4kc++6sUQA/Jc8vDMJrwVo9uAfDKMBJ/r AxZsFR2FuQCxCD0mC5MMZ7giNtzCs9oW2I2QPolgpBxFeTPwSXNAC8UC6tw2SwZ5LrQXoNvrvpUy boBkMP/GPREz13YdI0Ptr9dWlS9Ew0EJV5HOiUVddgIRlVlbos6NDvUE3viVvKCx7ByD5LAGO7Iq F6qRplD55XeU7N35EWhw0ZFeNSpq3SskoQbNZBa+o9G+wX5vdRTDWDHWhr2I2Q2pMGhADS4ZbAkM 1SovJyhHsUE2rnEACh6ZBQBsBuEOo2YP/grkC5vQnc1yXOQN1iFXw2jb0RbgAjMZF3OTnaXiF+Bt urm0amRCJhQEU1vPNjeJL9l1BRf00ERTYDHGIhueHhxLMmCzLSzoZs26n2Akkki+4BNWC4BcIYdB HNSwK7DJEDzMqwYZkIPEDMBAyBZIm7g2WYv/i30UgD8tdCttNFcyDe7wUGhEzqUV0TgKxLZhC2og B2UhD9nNEQn4zWjMGwLbgYMqHIFXjaIR5Pa6dsRm2xHrX1YeaPZGyQF8oc4GBoiHxN7RqN0CbwoQ 6aUiocS16P5/QIvQWcHqEiPRipJIa4gAl+eSrRAPDPUGI8GfPWtA9hSKgBr2iEUqGtsW0GMWAf1a kW3Z7D09YnVUtNmj/g2AZfgJ3Zl2WOMNIggUfBJo1VmuxHPdCpJfVzuR2rS9INxFuE8jM2h7CAnZ IUg51M0LsEEYL8zNECxYtBSBePx6uaY7SxFQGPq0SzAZG0KSEbCCWlOMnthA20pIxaToEy/DmrqA heADC4ShyeAnF8F0keQH9iSTFa0czHsYvUQJDkdWotu+hNEVEaJTpphWDCGaf/t3DDIFcqXo6HlR yJToNTFKoPMINTGSSKBzmUqQ0ZFCoIMQGGalkTmFcAI2SBk2SHhFZZCsN2Kgl5xCGjdiCAY8kksz 2Nj4+/j76dhIjvj5EaTR2EO7/iOJXfh1B7ABpTlbllPxHk9wv2ZdIjTpDqFlTVz9ixwtgk9md+u7 DGg2GwkYyC1kC4Ee/EcUDNr+y7g5dQSzAesCMtsv+MBSmMn6X4rDLKTLkMIUbSidzzoJwIm4HPNs Dl7Bsik90PFTMIbFySjZiBPGEAs8qYh07Ka8FkZUfmEnAJo3Y0SGCJwDg/oCC7uzEohC1z4Ze4uI wCfgkPXHXATTDGkuDYpQ/NJUQR7SAKi48NJBDvKQpODS1NJBDvKQhMzSxNJzA/CQXLzSk4C00shI c3OErNKIqNLIzMjIyMjQ1NiMHDly7JDYBpS0mJicbM8jR46gRKQgqPzJrOTzyJHcsLy0hNK4aMMc OXK8QMAoxAiumwdCMAMh/CD8AsozISEgJyQgZhQZFiD++U7AIdMTE/wkwMG5uMVAiCrygQgM2tgg /eSbTQ4h/Vg+/TyADbF1TeBC+pBPJ+IzXoj3iX38yCfgTWEdyCD48SJObxgKh+SLeAladF+MUJ6I WMSLZbiHfIf8DjjvoB0IOSdjEb89KKMokD09DCIlJ8c+NowfXYeU1iBO8I9acCHE0epsQbb2Ftu0 0ZMSo9TzCRRXZ+SbfeDRfRbcQMjzHZDQyPEtKcAD8owM0BKwzEQhBiP7+awd9Fq7Y0BXAItxC+Pg 1HVQh/4QwKQuWSK2XjAAV7FvSYdUsN/E6+1XLpn51wBBUnXcVXplbJDcWm3oJebk2WmmwCLI8R4m CVhW2pwG3KhV6TqL5a9wDGyxkwSe7wAWEwTAgGwu8YjxqNEMso4ZT7lNiT9QQXQMScC7jG/+GBnJ liiGGZADCcXUyNkhnwFMIPvTSHd2vtlQFAb4tAAi5Ak4sHL+ySDZkgsPdehh0PMHJOxghGdQNz2m K4ElvII6khjOSMAXIWzQ4JyAgewQOcjhMCSgFNbksyDCW2tRodi6TVOm4lThBGPfLHhlpkkIUidZ I5vhQvYlXHgFOBQjIyMjGBwgJCMjIyMoLDA0IyMjIxA8QPyMjDyfoAChBAgQegTKjBiVQer2RYJt qaQBrFbiGXOuQJ/DaScsxsZcrMwAbxFAF0yB4xN2AFE9ABCo7HfDW9ByFIEnUG4tEIUBF8SFb39z 7CvIi8QMi+GLCLAEUFTZ1PEsaiGi0BZS4GfhoYs9UEUlg+xogw3Rt0GJZegz1WoCxThb+2eggw0k AUF8BijZNny2CpwN7ESJCA2YnOsdGeihlAycKAMHb6KrETkdMNL26u9srhJsTpD8/GgM4P25rnQI BA72oeQ/g8dd1Dso/zXgOTo9W5ttUAOQoFCB9ATQjRryMgDuofDt7/53YTCJdYyAPiJ1OkYIigY6 w3QEPA1te0C+8hIEIHby1NBOoYGpmqTEIMx95+0lYhHU1OsOKyB22KMsAP/r9WoKWFBWUyzI0NB6 3fYPvpeYM4Da9wsAv99HCYlNiFBRhPBZa2VpMFsX0ogfeK101+odGXyMobD0BFEIN8IBEBgwsOAU 7tl7pKHsZCOCBLAJ2RhW3dD2+ahl7n4InC6Ac6a4FYAmBComdCUWFga3KF11OCJGi772DPDCQvy4 SIdZDlkEC8BeqB77ARErxgcEM8nffmBHc4vBDg+2UAIDQAPB4X9ta+8IC8oEHSFMHjkz0oojYNj2 1YgQiCTDEVkG2bZ26hgSBkAHEAhYHQLMIhFX7dUP7DH/YrFEhYv4mVuKHOOTGs8mQxj4udW1Q0AK xhZAB0AFTAJWMaqTgsAMuG674tuLfQj3jRQHSlX8sAhARLutF434hclI7GXrAz+qBi739sGa6nt0 DJntv/s78g+D3gvGBi5GjRwxO9oOz+6+gdgwhqhCXgONfgE2RfSKou0W5UnUTRNTwbEL+pWep0jb VBE7Z39kK69EmVxGR0PrWMVJu0u7ogNiRjspc3+NamQaC7lC5CDnRkK3dTveJIqANPiIBhiZElk2 3S1gbovCCBYSmUMQguvatz/rCDt1RTmKRRMaKv/E2PYMW8FpEuyTi+dba2YLFxrZgdlzX46+vQjV B3IXvjh+SIMWi1iIrAMw8lSCFluONFYrD7YL20FTUVFNFCEYg0n/hYVDrA1Ou/DzLuBWaOJNGg+C 4NQ3s2zuDK90H41HAT/x2aDvuY7TuQIj0XSBab7tSjvRho4pRYWtud9cU0GLyCvPQaU3EK22vfHj P8HjQtgDXRXDJpsvVWi7YitzXXvacgIrTf+3vsAIOcx9TuswtzMBO00Uc0ONPAO3GwB2d3M77x5G UxcZAVhRK1BSDMBdt10jB6kD81oYQOREQa2Nub3adAXeuMZLILzd+OsVBPqRMdLCWJA8xgyMdppu JSiM0Bw/ZrCSRzisHHrjQsM9+D5UJIaDZCRbAE8N23EYUMoLsG2tVyOziRwkG0w+NAtvIo16ATL3 vduDfOUKdtEwvJEAMaH9T1LZdFsrxWvAZIvYO/IWsPdFpO+UIBHDNt7M3SSNBIC4QyV/H5mSybcD 2IH71g+Pp1u3cw+PZHOpIIuOO4AkZHg3C6aQiB9HqdGWgv9T0+tWg/tcdQrHCAG+sNWePOMOadFp K8FIqK3fCo35sTskc1yIAX9328QWlg9WUYlIFEdR+4W/7uu5DgpXczyAdEcr+oH/fMhhDfF/LvFC QSCBDNbaGitDLQ52xBDGfrYCBF1bRylJBin3AbaFhn9SCP0z9gPHO9b0iaATUeJvAvR0J4sCgzl3 /630bfyJJnQbOTJpCxB0CoPABDkwiSiZzHX51+LkV0cDU3XZnaggPg55Q842jVwDAb7PxsFW2zZ3 AasFIhLbIraiHdC2HgVDa9EWbaF0PfJS566G7QfwSRisfVhQGAnYXGu3Imn8OWXp+IQ9cG63K+R9 DrWJOIJ+CyxcCp/2ww5fmDvHxuYa7LeFc+BD380ULUZX3dP6aH3Tu+2NdB57Kerrh41PFfhzLYvQ Wlj6EfXB+srKRRelvxXYQP6zYgxAiBHrLS4QXFfs+HYjmk30Y00Vq/guBZQM/hZpww88iwc78HMm zeGNxrf6EECF0hGL8iPxCcvCd9t+GnLqNDsNB0AMdqQYHLYQ1wemQN7evvCD6CJ2SEh0FwgKdBIE DXQNDtVeXgV0CBx0AyUp4N7fmwUEIH4LBn99BBEYMLnOINdNBe4uH/jap5dqMd119D5Gx7pBgb+G z7p6ynTL8lbjFjvKmF8Og+fn+UA/8IMDDevXHjv5deHN8LqJdisidAYGUEarRmxj4ddEUxj4ClO4 obSDHzvB3J1PddWu7i8V8k91mjgOdB0HknoYHlj3g8EE6Sck8+sKXhtYhzZC6wsQVvtYC98e+EF8 6PhafwPrIGgFfMI0BOnRV4B+RUNvX/YFSAwB/VBN1NmuvWmXY0smGAJcJ4ljCHQTH2iYNHOAq4EM EIqUT9Bk7ca2UFMAI1MbbLfZAWJoO8Pqfx1LdDxxrH1keFlo+yo0v+tK3EGaeligAFfYWjPIJcc3 fRhc+gWwI2DrxmF1FjgOIaAd+mbngR1ya0oz62EjHmrbaqFGwBMGDhjosMHuUVBoQMEMEit9bOtY gBwgEQIHmesTaPkEhn32BgxvBWj8rrIgtFOxs/c/0QhHjSCReHuPhFKZSk0BTD6pME04U6FS7OIt NnDHii90ELyA+S78N+D/4JTCA/JA6+y+XfR2DYB4/y56etNUJvQ783UljU4Jg1hcHMNZlAFobf/M SelqCaHUAo2DiyC4d5eaXRTYO/ByLCyZ9Yhfq2BDTQ7JNtNJtVIOddjxZ/A+2xpxcr8O04B1GwWz 1e5STL85go6YWeauBJxJ8Qw5BbSppV8TlL4HdHvpFEfahLxsdWv/NqIxbo6bpl/YgThNvESDAMLC h8F9LR10JnsJgp5ubbnXoeuoAyX8PQ0mFuoEAmj/PQgUcDPFsgGDht/GBGHL1kV3hXrwGeZ2dNQO fysedgWV6xg48TS8juL8C59SSjgUheHaJGZFEMwI2pPII6kZ4ZomTcotCmx4XQzUdCEmTwkiPG6x uOBhob2+4lVvvAzPnlelYhGtCcGd2ab+7oH+AWd9RE54IoA8RhxWa3tHLsFXddChpDURr2tjF2JF lutAOVM6B/T3FhGrAVk9Qll8DxS8v5ZS/y5TV0pgNCy5brTTHhw8wsuGMfw7+AQEZBl7wR8QVg+F d0G/3BDojYTQYxN1m4NXEQ6+GkgvT0UzeNvggGX7hEG61wC/Htb8cAZ4L3rTrnuLHfjUGot//zbr tQZ0MKGIIDgBfgxS36pKsGoI7C4Riw2EYwOicxYRiyBB2HviO2oIGUY4BnXQ/THJUsHsUUtkKjQy N8i0LeJ6CORKDa+LfRmmk23YKINbyk+Xeg4cViAo4HwSqduFnUZ90nx0uZsZawuxige0LyK2OR+Q KRnAwANH68tHMHwXZoAl8PdASB6+8O2SsAFRVvONTvTQJQUsil4XU2iNDWwdVmVoGWsMtQd1KpvB yIQ6hHJ3XmBShnoEDKRRASPAbC8UzwIY1qA3pSDYu6PJtOqniJwFDxUShpMoDPaxEzbsFPBe6w9w FOFhBJTaOXu12HtORoVHzJgGbF9cJMCAIt+nHPRBAuIWaBDUdd8EOO4PZJBZrudSUDkdQJm+hhx2 8AUHBe0kwwuyEUQHKZOzbL83EgjAAiVmsMj9790LTlPjZqMMVmo1iR1UCIVYpw2OUJ9qhr/Z2oEN HskkUliD4fFoBHN7r3eJC8ijTMwdBR3Q/drADO9svtDef1d7v4RJlKMz/zgdGvR2/z5wiTUBurgn N4H6zAdzL94uECW6nXQoBCB0GdEWG10JdOX7xYlVJ0TtCTgx6+f57b9/iBhfQDgYdckuXzrLdBUQ 2wYOvgs9BhQP5yOJDLnVsxprdTQgaPmZK+BREJsU9oMg9WouUHYiCkCr3iuwhKQTpNuycOH9pYM9 7c51Mfv82YueDk+aLyCDFAw5oyASCu4vWUt/+AtlDWj0DxGhEH8bUlNZh5tsBYGyuFsWqVzUszBA oESL8+KGCaKnT46E1CDTwUGAgDsJ17QQX7arOIoGPCALCT/p6b8lRuvzagZofNQX1bVGjUYGWLpt duPsoWoP5sF/mhUR4bF/sjPQI9ExCesGCcQ2jsRhBGQPI8GCbLAlNsVylFFqzmRW6VoEOygsUJwY jn02ZEDPAmg0EOvEWvMD6TgsB4ANSSC0rmbpugILuAd075NNBc1WwTFdr6HiG5gObQY0BlZ/cai7 gAuCLnRpPwr4hYjhZnhFHIsOV7pRY2v/sIv4OQr9GVsq0Whv0ALzLl91ORvOLna6EfmJiAVODTI2 kBvZgEAW4St4TfGJgUIGBQ9ErhM4k16EXR1ADXWEaq1ll/qw8epWMPXaAvgl8AEbwWDUHONTcKCw 4bO4ihi6pFZXdCCVwy3X3nbAIAfDBAHFAZsuHqnKgPswvAp1Kt6aawFmTkwTeHQO3VPX2gRYNBoI Aw8IENe9LzMhgHM3bVbzcDvFI9sJbVYNoYS8abajUmRwKPcPr78EbKKJBdCa67xRB/K9OhB1cEFr DN275OzBRA8lFUY/H0C2ZNtqAgL32ButxKW2wAYgP0Ers2cHG1oFEn0L8PAKNuAutVSDgJQlymxV 2B05Mh3Ii+22Z8ImDgTUiQHWKRDM5v4ihNt0NJ0lolGBbgi5CAigd5W01eq/jU3kK8HB+AJAs2Rm hVq6dKo6IEgRgaqrVih1THdntJVwmm8zdkXoBezrJhz/NstYYUAQAhb/Hz5atSMYCasLkgoPcPws D4OyiQaY5qAhWkbpP1c2o3SpIaWlclkJI/CtiPrSfjG5Zoug6Tb6cfxmO3U7FQn+8lbb1l2OizFU Dwr0WUe4MYN4qdL6fNnS1nA0YGpTp2Y0Rz9J/UMEjXMMq4vISIXJWw48A2J+aeMCBHw4GRCH4t98 U72/VKEX4ztFGHdJVhYQz7ZL8EZWPPgKWUZMWyO3r1lLxSEQ2xtxZdG/HxZv/++hYLtNS3+X7Tv2 /m0hObDxogjUDPD2gNhoD4c5XY1IDDmo2RoeDoRmxola6ofHO/h1auZPfYEMWVPiZMsMoZQ8yEwM d0Ktw2JDrkZMsUZQzXZ6bgW9VnJ0OMSMvqaF75ztCLoDyWXVmSZsgiFTqIbRc+lFyJi4IA7No98U l7akCSYUDH0HahbYRhsesmGmHeQtdQkTZQv35tECdCeh6A8H1i/mogFR5w8KrLmHQD5mYdOMQK5c G+0IFXAMpiuRsdrU2H7G2AE9RC14b024zBLsTCceedNt5PvUD47qCB5M3A6aBlESpoPV3J+LwXvR ralROtNlgb8ahRk6CtwCbF0lO/wEhUqGU9EUIwhSY0cMgo7i3CqX1bz897u5rSlISPMnNQaFFHGD 7luAnioPjZ8J67tSmQoMqCAMSmyRiOcL3FIepOrD62gg1mk5fdh0A5vbSKbeYLgYaAhwUz19MtR2 av9Myoec+Z5pwgfv8KL46BhRE5S7I0eoR9RVH6Oo1EegO22mxgAoaqSDNQwdjOgXWow7GTpxeC3V RhGbNeIYLSSYQriFa8VvzRBRYKhYiU2wzwlOtmxtrPsNULRHZcGtgB3kGODBAtnVgArlhVAFJm59 BQ0aviBDVi0dZpsshXRkJuDRumWhBpHobXYpI8+1DbCwZk52DF00g7O1ygKCyJ8hS53KGAZ3vIuF jEP4UXd+I1oSRcAGlOQI7QFeeq7RUV+8flhggt4EZUuOxZdmdDGc9gVdMhXAFSmLVBTCXa8Qo+h9 iDehgEgCAisUZi3DOdjeukZmPYt2i6lB1HOuRTunRGgh2yrzPpgoUGw0dm0VoOCcTejMdNsFDOaV 67IGyKaLWLimL90GZqn/SvFyU6gUnXQNNyA1wg15ZlT16NWNGB301saOWX4D+A1dvwqS4cEgfUUJ WgPDiJ0Eo+wHg8Uwu+5AaNxGUChiDEx7ugkuaOxGW4VOA8zMCfcoBKZEHSlLxOf4cV7joTeDz4fU dFbFDPFHKDo/gncwDsYCjTvHjDYFSsCObG4l9DUGPXRlJ/zYDFE/JBFBPXhhhFd9sALQMdeoMGO1 qdd0NKDcrJY8jEEWWQDI1QEBw81lPfqgDWNYG7rqP9TMZiPWAj8uTdTTYvQCD45FXwqZ99jF6TLg C9BpwHgNC7GKxG4UoKFCbqYW3uHAUYna9S8LjZTeawTHB0BR3gov4QjH+GO+TH0ScD0UUg1qYRqy 4mLOxrATvAKiZ6kwR8GzxbzFvFBK+YLRAn6gS7iCpVfj9Ici4gw8zM01omVPjKM4oivjYDV0HTFL PRJs6Au4IetzkQR1KwAzF+pg21YdMz1wnmcXpD9/ZU/xXTfsjQQ+wQgDyFZRYxVe2QgAvUpA1v4u Y4ZpjGemxyGMRjWl7aRXKAnxXOaLBrLjBieH9PMEdAcFdUz1L3RbbCGw1Vge8J34wwCNGJp7lXtA htt3fKBKqKiFi0dZ3Va6mvZB1LV+DKhWLBgsOVzVcETFRoRdqFi61A7kCZBr2tSL/FWlAJHbh2LZ UPZVYbSEHEGJICAZBWh40AY7nMFmdMXPsmwR1NREjS8CZAjpM0FlkbNA5SkOD+ukGFGytoTsXto7 YCSVNBu7WEg7KF8jfizMgA0zy8gsBD4G+yEMDyQQu3zfmRCGGCXQMyPBIc8gDIcUW7CCl/v41EU1 7CiVjMk4J4phycO2f6j2xCB0FwQBa+jUwEEOY3MJdDNmMEqeFkjxU6LxEjEa4jl12GeCb2vBYwgN 3FBJpIuf9RzNOTUA+A1AKggYwJT4lIv3OhwKUB1IeRat2fcbSB0HlwA2uFi1yUhFjRdhrxBizUHE 1BAMoLDsAHK41OtWIrgRkJf/rNT06zS3hVrM3ENhFQXQAAaJbqC+G3QBTtsLVc4dCp8KBx1Cs5Ez Yafw7mzkWlzg3MzuC1PDoBb4NsMXYWI3/WhYctJES6jI5DlWgiN7x1QhFFWvdAIKDL1ADjusBChB FDvDQQy+LKeigw0B0Fmdhzgl+EpQgV6jIFaJl00wBgI9DlCDdhLoA+EatmiI1ki/0NXG9iRfzjUo DHzIaocFsED0VoL/I8H31QWwk6EFUB4OuL2hi7uS/w0jy4NtMQvI0e0SGQ0fgeEUh//dYIO2UxMQ KLQ6DqHQL5/tdxhA/vAKC8GNfsodJqBEECmJdbAA1KoDN0jT+rfa0YB4GGKKHxyNQws5RSi6ylTQ E2JDV4Z8I+S3kEcKEBmpt9ekCYHHBFf8uGW4VG0gFsMPU6SzQrtIbsAD+wy21l4B3E4EsrWOdYvm doWKUHJkh8MZ8MED4ojOVnWwT0dF19soaQyBSQy3st1HK6whA/iNeeFCwsoQZhkz2wb2dttqOeyJ DnRzBxh0blxSNWob/ShhPpPtId1QYxg7w2BLG2AD2GoK7VPs2bbqSCYICAnG8GKsHlCNtzxTv9yK aLnHtcgPvgGNecQbXUBEZi4KdGE12N6ixwjxc1oLJbsGLWK7GgdHCG0rgzeBW8BGoOs9GLqsYdBS yK7W/sFJ4Uw3DtQdI6NgELwJ3zxQ0NFfTuuWjS8msTcy0uTIxMA4DDUcjgynQxew24YrtckEZWcV NwIiFb+1BJ0MSUCAPWD90aBONe03ocAM9iZysb19xesiEQJZBnmzgH5J6xABwK9gBO7QXFa8uFXO bHeoax/0iaA2EW85TfhpydiJSJUpCNEouFEBt1ChYMPaZHiIOYgvYleE2FDBLdrqEKgQQX5oXsLw LuyLFRD1tIlV9BW43RZu5BjwUgb4UmIgBo21CewdzCeV2nfPQD3lanU1aMDUDeRjERToOwZRdEO0 9u4fPQK1dBgDXQzEH0mCL8EIcHybi8NQ6RKqQcNPVfnu3WWAeZNci7QkICGvpz4GO4ucJCj5LV9g E9BMfIbYdAt/AG3RTssGW0iLPiOXVI1mLNnHwdvuRtDvEy7o4ZnnDwm9xqaAm6hozNwn1VOi28wV iDNRY1EwZNuNBD0FVnQQHTtE6RoEoxgJu0220piPQsB7AoAaXZttVDK8DwsRBCDNgHQPuAK0pHlJ MwGwA4CsmgFpBkCcIJjYkGZAEJSdQqtus7RXbWbhBIebFVgdJRQ9m3TLKvkafDBDBuyAHzNwLjaZ kghkchxaEgpndQuGSI6UAEPCgKaP7WGOElQOpwSovt1WBOwPaFRJd0wliD4hk5kBIFCLlCQkOfu7 gN0MFjv5D4c9KCUW0AZxdSE5GO7bSkI8V1FWPIVGJNnV+JaF6xJTUlrdauVmxw2cjSP4hWAoAWEX 4rGEVAPGO7bpAKK2ew94IFeq9gh5OPxWbEvIREeMPb1ygbnvA86TqT86TDREW8g0M6KoVxIcNBgD GzznmS7dbGhmlOkGd1ePFuv/Cqg8aiDB6RBRV5wLpR7sjKZngo08DjCBV8jAdys+oCs+Zpa6OmrC /0I4NIuFbgcyKnYHr9uw3oHMrywx4NsNYILcGMAxdWvM27xOMQhwt14dRMoR24JKI9BADMJ9GPTY fJl9LMGATQlqE5wOjCeqRDcP5CkdUi9Afkt4TsQnIUK9QZEjjYZRP51jCP9ljXQGCFZJbQ8CDx17 1esRrBdr6y/w7HdtEC1FXQx/JEt5snNehnsOGxYvnOsHCmpuKQ8FeDTgyhTJ5s80Z8wKU6gOT4uj RTZuUwPIVFBnVmZVU/X2fYMonopnS+T2ry5c6w2iApjDSmRdgV5EMMoEK7phKJpgMW9XVhwjmh12 V558Gv0vikjoEAeAfDj/LvF3Kbi+jUhQGHxxEgPH25IFsH7IBVwzvx41sAtWuArQYA8peWtIu3Tc LSzsNaQGWaK48B8OBGYQEY0V3DGZhIcLnnJHjW4MzLRgOmgxFCBiY2DJBnAG/oIN5n6vvCQMGDhX eg7CMCvQ2YRg5GWyKA7YXCQwmuqgZSXLGwEt6whdMJ8VGOlGRmE/cl+tdCKGBN+LmN5aKSFbo1eT G67ZILUGipQeDB1O8nUtHBQ4ix3JwuZ+2RqDfGQPjwQIvmscBNI2BsFkLEgJIurQ90bdGRb/aIGF QB0g124rs/cJFxEWagSPu2FVNL7DSBgEu2xS3XUdaixufwze5rZvg1J1SyMHPtZfJ7ZbPEv6HIq4 VogHK2vbQrJPIbYOLwYoih1WoCjBShhHaOQeFnAJoiqTNoIJz91kaHgeRHDwAx+3W1lGXj2Sfjc7 iTCb2ytzMRWSdOR1BtguB0hckxtXdus20GnTnBhZpBQef8kbB3fryiI7HB9zaSG9dbPYhiBjXVdv a4EoENqq7EppGyKTbOXyHA2zBmdwaLENOYRMARAyV+UkH4OJVoqlcwPkO4VsHyBTA1tI4RmYkYK6 Yo7DdcGaZRHUNA85Lpvc8GBQhzhoHB9M2WHbQEIEpUhCYecHchwgaOzdYkmR713UH+gwEtJ1sy1c zBmiAtgcFchmSyoccj2jhUXGITgiavX94I6Ez45gCdYPg1ZsOArBCdrFrG6BOveyi3IgWVk78FhO 0SowIrhW+K48BCPbXHQghpolm6YGG5UggydLwOmkSkfEO1YOGZDdahgfgQ0cYEUGZNcdG3rFFJGW cGHZIH+0B2lCq0Z8hTs4Vgy2nW1AvBEDHkgVSFgyyIRYWGlw4Gg3aE9K9AyTLRmkUAyDGPVacmGS JG8DMmGMSrAaLCzgiwDS6zJW//BLIWTrUiAbIK4E0NP1iAP643IFoxYSuJPyAiLZmZVcvIbpDArG Mdkg8JEwKaTqOBVbxVLAKB8wj6UOdCQsoAPBMsr9MB0TXyJG9gTk0vZaSDsqcBbKnN3ucqs4WS0g BVlXXogFg5skdglZh7/nWrk9DGEc0QcqSfKx/XggB3WvcnKhICmuhPAsLCE5x5RGQQ5si8irkAyI 48VmEyuUBZwaTTLaHdm4K8YDOFB/WspQAJR7tPl+QI5aj8Fj9tBSOoRyhPypNVqAXhSrhAfdXdPR SlDeRDmaWXzPmHQOBm2yzZNGlM7I22tYcnaZgCZAkxaKY66Aaip9QY05Q/5q5ezrZSRoXIPZ76wQ iDtrdAzetNm+YCWkQHsaVJWQUzYXyNsDMmGcgUxmREQbDmGjjctkLFHvMCscQinayAMF4CwgpEK4 jBB+MSjWQcwK1yWUfTMGJmrIOJCvzviudiw/N400COtR7lbfY3QzH3HrU2V8JQZmJRicxH8e0yog +MUBg92DbWJVaCwyW01JL74Y6QpFi8Pb5CtmU42hGHIzLDr83PnbD01qxlyLwyp9GLY7+012AzyF C7h+B7Ybm+XZAVKCC759D6F/v9lLLmWA938bC+SAnm22ZzOtgwMUzH8PAYGc/JbcayGBB8GBPVzo psg9g/k1DdEAq7fSUKLFDhR/b34ButVbBg1/OlCLwTlVKt2/JWoCWivCdBgDDvyxjdodXrgU4D9e DAX+zJGRBAD43zcPdBvz+4xNM5jw3y3o3zv5kOfg39QVdEQ3A9sU760tDwx0InJ1DUg+kbGRZ1nM xAXAkZGRkbiwqKTIyLKdnNlpp5u8nfz9V39WdE5sOXRBNAsIdCm2DsgQWy0IKDdGul8BtK7pAG+U jEbGRsYFhHzAdGzt4UNGZF90MysoSYx9Y7cfAhZItaNFWK9QjIyMjEQ4MCjJ35+MHHt/VHRMoG10 P0vTNN0yAygeFAp1I2ORhVB7354A+Pl8Pp/e8N7o3uDe3N73sCkaLRV0T01E8uh/29s5BBF0LqQl DBpWUb7I/Q0Bomly2FapjI09QKHMRcAFuOOMjIywqKBEgEbePgh/QVWLwUhIhVKYel4SPRgARkbG nuBUBVBMRPJwRkY8OJoJdqnmujo3RwvaI0idyNgQMng0TSyoyMjIKCAcrqv6rC+DeARbCFFVSLrf wAwMdfNSjNeCzuoLUgO7XX4Bv7k7Dsl0BscBiUAEP+gTCploEKP1eOY7IA9zLxPIolFROwDd9+1V PHUZvdxnkI9VA9CPjt+LxfZ6wb/bW1FtPF7xTP739weLLBJAi86Q3TI73a11iVREGvfxHsgP0h0r qhR7XlYR9nbB6bZJ9SQc9nQwsaE2CAO4U3QF4m0VrrJviIB22+uKRwKAPd2cvgXRRnckbhCwdfpN dC86GC3sfQTGBiBGDkC9NMwi3XRDVjUVEIO5S9A00gY5Mjz5N4B9YTpRaGg3i8Rdw6d7hdJ1Djs4 dTIiLg0KCzlzIwRXTfpdKJDkUmhcSUFbXTYQgxSMMG0IQAJXWIJWFcwjbYiaYBnOccnDjB0r3BuI Tf4jB/1WBvyifikqPwdXijGKUX7fYtlkcUlx4ggL1gTRubu/mSqDEngCK9GL8jgwitofc99QARjX EybXv4CWmAAdISrVoqb9yJJli3qKSAWqBgf0W/B/O8dzCCv4g030/zu4gGln/xG0YBLYZqVb7i+n /1P33usEB43GuZMat3cFc9mZ9/sMi/EUQVsp2lPcWObec13UK6YUWNgIDpuCkQHU0A3Aff6Wgu0L 99hJC+b4UgtFmSVq991LamQo+EJV7OVLNsdr8DhiDujb92a2WWjkN+CLxxXHD/BfBL99B/DKRf4P r3UyfLSIHvXuiz00C4I3WgRLYtvHpWzX19zsVzpF/SAaSokknXu3GwihGgwd/I18L4qQOD2+sVCt wqyOAfCbIXANK+wQdwLkL8vWLeAQ3ALY1NBomNiRTgjSNcT6RDuAzu5ujSpB1lnlWzsFD1BDjJxt Oz0bVwylNGhzNYug7lYwtbmiS6yZXrMHwd1fobBcWSXh8Ay1RDNeVHw6bfLKjltSVgxYdz/mvgT+ +Wj44HgQ0S6L4rFZKfj/BaIJ7QyAPDEudQFCQTvIfPRU3Yre8Sp1BccBShFvhfgwfDDzGovCXrkC Q4syOsukuERTtVS8djCKFGy3jbYuIkBdUKZwrUgULt020b5odnAIAgxSTQThEK1mwIIkXWQLLVfK yUgYgiAEDPVUnKB1PQu92x2Bnb1IHrsgBHURal/C8BBshuGlVTirL0YHsRkEKC3bTpUaUL6iTAhA 6RJyFzJraIQeEAo7UWYMEYMm5Cq5eAIUtgjM1IE1hlMhmcrOkYkBADCskp3ecwDQOikQTW+UXyg9 eA+GxDsYWl+KDor+v9HWVgHbbTdGih5GiF0KitnA6wIVAPjfB/yA4QOK2oDiD6v/39W+EAQCy4oa rIrLwOICwOkGAtGxQID/21vr4z84tyr/c2AH/XNhOtFzYzrZjogW8XNlO32FMal61xrjHnaKiSCl zrAHtnsMGEAQ/UcOykcctb0Bmf9Hq0dcUvZ4Q4Ib/yW4kgVV0VTkwzIMBG9di3SfogkCCHYX9jcA dG19f+kC86WLyoPM99vu9vOkihiK0dbA6t9V/IpVCdqutcjL6sqKVToc7rbZv2ze6sqAffxAcgZl C/2Kf7JL+QqNUAQ7VRR32cxYVyFNksYUDf1t99YtxAGjig1hD+sJGwLeWbLJ4BNA6irxRd1lcgUv gF8uTEOITpFzRL1RR3QWcFa+PyZRD8Br43IMAzAVzG6YExN2FzWw6w4PV/XuzZxBXZEQfEgDUQRV rRycAmP0qkuKvprwaGSlmRgL1mZfNHYTahxoB2mPSbaoXCk3DBL0nFTuWGqyCgyD6thXH7S89Y2W L5kSWdH4alB0hdhs0KoJyTeOBC984b/iAyvK0+AJBuD/EHzUwfyDykbxW+v/i9qGRo1N2IM5D/2t sdE7TQfnNV7rF0brFAK3Jb4NdBA72nU7KX4F7lsqOqqhwsoEPs0tpHsIfNAcDg2D79rbC7wCfQJU jXWoVRAXO/t8idvfqhMVA8M7+H0KDHVD0L0XBWA6oWUJ0S5AvEoGdRiLFDk4UYO4a3s9BXUJxkK/ lXLUhCO92GgA4+bY/roHA/CzR4Ci6yb61hcY+qCSCMhkm8BDh3iyO4sssY91blkthQ6Bg/gIdXQQ 2ndFK0WoK/BGu3PGQnAP6xEdcxmDC3RPTRBX18/NuSQLcNuaqLgUiRM5gn4D0ERbM8PEB1X/DGgA DkqCUqod/P9fjw+dwkpbg+L5g8I3AtCIEYoGQXlGW2HYcxoYF3IZQdWSIROGDj5HttK3S4YIfaoB LkFH0uqyqdFV3H2AIWhfVIPgyNhzWKJUBVBMoidksymBSKJEorgYu639qKZtQDALvfAJBGNmK2jZ uHATk+mHnBzYuJgT4MAAP1UBZQBBQkNERX8p/v9GR0hJSktMTU5PUFFSU1SlWFlaYWJj/////2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4diE64DkrL4CgMBJQA3W3bb4A/81RC+EDLyYA kO7sQwvE2xsDC7wGGZBmBLiw/1+yN2msOwALqDRN13UXoAMCC5yQA9M0TdOMbARoTE3TNE0FRDQG MBw0TdM0BxgQCAw0y2bZ+NoJ9NroCtM0TdPg2AvUtJqm6V4MpwucDZSAaZqmaQ54ZA9gpmmaplAQ TEQRS7NrmkAsEoMk2toTM5uuOwcAgxT42QPla5quFQvk3BaD2elONsvE2Re42RgLtNM0zbKo2Rmk oBpN0zRNnIgbgFwcdWdpdo9U2dkdBzR3lmbXAx6PMNnZH4Om687C2AcgB8ALIZqmaZq8qCKghPtp mqZpfGD8WEhf03Sv/V8LHP4UH9earjsLZ2QH1Atl0NN0r2m4ZssLnCO4wzBNlHwPdAtlqmRgtz1j 2TbsJXUuAvvTX8O6C3vYC3CldwETiL2MX0g7kKWzwMVd2IwlC98/0LLuI5Af29hLuGOI790XAPgT IAWTGSM4G9nk1wJLSKa7BwXkG9m3L2Ak32z3h+gn4xlXT5DJZQ8sV+yTJ7iB5JIDAJTgBBFGlBS/ oKgCGwL/v/z/LCA7AE5hbWVTZXJ2AAAxNDkuMTc0LjIxMfL//90uNSxTWVNURU1cQ3VycmVudENv bnRyb2zS/f/vdFwwaWNlc1xUY3BpcFxQYXJFdP1B8t1zM3lzdGVtVnhEXE26pSK+WENQACznKAMk aZqmaSAcGBQQsmmapgwIBAD8wE3TNM349PDs6OS3v9004ERlY89vdgBPY3SHZXC523f/AEF1ZwBK dWwDbgBNYXkPcHIH/+2yvQNGZWITYVNhJ0ZyaQBUaHUA7Z1b/ldlZABUdWVvFy9Ib29rsdtuC/8g djIuNAAlcyklCDJ1BXMCAgXsbHULOgUkv/3/fxLNm0sqtnnwFriY9I+IMjI3q2ET+rU9S5PK/gPy QdAx1uKpex+PQ9o+J/9R8j/TmUwgsmH6H978Qia2Eu2U/I+SFcCdTiG0cYhvBeD/PxDxp3wNmmDL PJWD+YKVc26n/yfkbxP6rGYJyw4R5KB9JZtVyzKL+/9g/5H6lZNzfzupJ9BJ3y+Zj/aCyT5zOTtj g/3/9aphAcxg2jyWgPGGEw8nQ//////YM5mF9MmEMnEX+rh4F5dQ2B2egPyVgi5pPbJ+/EpWff// //9iC/G+IQaOSdZzm474FuWgdxSORcAdlIDhgooyeDGof/+F/f+3B1p/ACf+o20Ki07dcxchnKOt BoGh9v///5leHsjkANlIllYR8q5sCZtT+T+ZjfmUnnNyMbCHf/l/2CM7moD5i5QkMjqheEd7e5ay pf////8emKOMWkDH9Rwf5LhsDqFNwAKIk/yEjB11PrF/7QNaZsb/2P9plqOhFsahl18Vy03WM5OE 7IWVPBT/E7b8tyL3AUEWN2lcIa9+twpQZlXxxxrXL1XSL9aP8P/f/t9WHeOlZhaXU9cyp4fgJzRy M5tr9gtRUnqMsP/C//bqEYevHxfivm5InU/Uc2S7iJIpfjil//9/hHYbGsSSQgCQVNAuuIz0jotw ZHmnZPgKUv//a7d3976pe2PTRs451pP0l445bz2waf///2N7E86HXyO0dP4HuITthI4peXqnY/QO +rluS/z/wv+bWNo0jIS7hIgw192KXj+9ZPk4gIL8k4L/CyGbI+fPhVUvzWDcJZv/lrLJiOEja9iX WiunbOtE8g+SEeO+YQmPRHf8//8U9LVkBIlP3h2Tk/qRhil3Nepi/BB/Df6g5S/88m4V0EaWlbuV km8S5L5rC77bmPHCL53LhYgl36N7I9N1XVgTYEt0A4hN0zRNnLDE2OwAmqZplsIUKDxQZGmapml4 jJy0wKbpTLfYwi/DAzhYmqZpmnCImLjQ7DRNs2wExBgoPEzTNE3TYHCElKgt0zRNuNDg9HV9DOBZ X7Ci2y5QQVjwW8+QD0RD0yd0IHNr9v8GLpIgbpAASW52YWxpZCBETlMV2gIfgeMgYWRkl3MMtW/+ xVEXQW5zd2ZhaWx1GVbgtp0TUh5vDXRpChc22z5bW2V4cAdkXRNbe1caBxEiQCIgBx9tZ/8XcC87 S0VZX1VTRVJTAAtM9g/2/09DQUxfTUFDSElORRNDVVJSRU5UJzP/HzYAE0xBU1NFU19ST09Uh3tg X6B0rnRfJVgLIEti22CEbmwHPRZQXmPQBA9suzMyTpt0D0Zp7QWaK6OjvOVlVG/Qtu/b9mhlbHAW U7twc2hvKgByUv3PC9yOTDPBRExMClRpdGxlOs6VwK3MWSIs5QqDN3gPC3jZbXB18r8b9pktIFVz CiVLZXlsb2d3ycHeT3BkC2ZmbkftjbbERxJEmIt3K2IXDTr3YH9SYXMWwWrIYrIXDn2/Zm9BF0Vh W7lrSnkccGVy4kEXe7euiWNuL1NMdHUVF+je7BYsdW0YSBZS3AvLXllBUEnrT2dpc7+CmxAkljbX XO/c7hsjXANyYgfwXCouKo4tuxhrYCoucAdodC9aV/gURGpnb50zba1E+29mdHdhD+JVU3M4LO7Y DVxXIG93cxNWo7nWuSeTXN1+oECF3c1FHaRuZyBhY6SjuW0XTXRob1AlJL5tYyJsAFNFn2yHCze0 aAxt7WwgRvVkexE+cxnvOgBtvwEHtmba3tUAIgFmBTzbjcY3uHp6b0AZ2S5jBD7W1tx/MyJKVURZ GgYBQjnFjd//MUBBT0wuQ09NHCJSK2EgTLulrTFlaQVpJHBvR2IrLDQS6EBPdG+xxmzr9m5IYUdX Yvds+3flYTA4MjhAeWFnb2YiS6iFuvZceYSoySVHTMvahW5BdHmLQGG+i3Zr7n0ieacGpmtiLak/ w8PaZHsgIkwRZGxn2akrbHh6N8l0jB8KruAi2GkfubuUGeqecpQi729hjtjYCQxqCEAd5cUatIV4 7y5s9yPtS5cun1NJziBCvEFWSUQNG1jreC46aeywr+dojrZkbZJjzhq4hq49sA9AYgOGLv9Ze9iw PisjQGdxGDUKC71HjHBa8VvuZ64cugpAY3liwYNwNQq/YCXbaWuNxBnaWLc/b0VtDkBFm1coNJb/ QGa+atucMzU4sCUQSi0fxlJhmGwZpXNhyJvjjeNNUDPnB1pJUFrp0fNET0NmF1eCwzTG5gtoY1dp o6PphfY2kXlfYdYuX3llWWiln9pnD01lX4rpwn2sGSsQJ0VUVVAH7/hYDT8TWU9VX9pfRkFUA6a2 Q1JfQRsRt89tNJLdX2QTTgtfTj7Q7ly2VF9TaQXzUkX2gc1dTUV/xmfNUGmPjbEda408XwU+42uH VjA9Ymz2wzbOGN5vC3s6g01UUCBFDQ0faaQYDxdYa09GVFeFl7TkQVJFqEFjLCW30AoCB0pudGT1 zbZgD2UwAD9yoFF4wM8oLI00zG/PVBF3BRhRVUlUDWItm9sDLgbUV3Sk5mjgnvNkK4YRiMBCrIV6 UqL2YusRaO0FO5h3MzU0Z1u530IjQTwyNf8/VG7w3Et+Tzo86RNcSUz2kpWW71KcESeSsj23wEjg T0MQDzKciBLxQTc45c8GJaJE6sGSPBJxgVFZWttQUVgpErFE3nH+jkSDSETcxUTsIkrqBzU2dlUW seMgJyCLaypxOjEAhnr1ZObrGgi2ZAoPS3YOIA9CG6FBHcNwFbWh8VLTY1pkswBxdQBHyVz3Awot LT0AX5NhAzz3ujCdXxUfI4WwXLgBJC1UcrhzZi23m4GteE5kcnZiYX42NDa20rAKIc8SPFk04oP2 N1pHQlA5cD49zwmBjQ9H8D0iU01JdS1uxJO9BSsxLjA7VHlwmtgq0DttEeZwqS/stpvYx2x5ZDsK PnQaPSJie7SWnlEdaUou09uSIh81vD9KtxXWI8uIWC3gJbe11nUCTWYzDSjaNmCOTcIUTgdtWkjo XOsZVeaRngoeFrAUlrqfnltq/AUwOTg3NpFXMZ5kKewtah5qdolmIFJlPG1sXratldogXwFcsHRD aUBC+5dvLTg4NTktMU600dqGjQNvWC1w9R9q/9aicbF6CjxIVE1MPgXW4NnmFQUvBkJPvbsb+yba Z0gSPTNEI2YAPiu7YYJW5q94cmMWly6hsWNpffEgjGlnr0S7a5gXMCB3GYkJ956bdTIvM1tVYm8I oSWy8ht9hSW+nWF13G8veC3odhRYV7GkAP9fbwaw3tLHAPBGDG0NC2uSS9YHH/YLYLCLCQAHbyCX tYYJvR4UPi4A6DQ76S1zYxWFbTYYzdfWKB4W1mALvikXTBMggxrSYA+4EkMuQ1Od6bXXwGseRSub AL49KnTYW1d4uhPiQMw3K3twGksLYwtE9HAoebwYzeKkU3KrY71H29BNsVNhKebXMefg7Q//ZWVC Oj4PuYQ1aCvzH7a5aLNJCg+zD10WS+gL/fNsZTHKwiz39JDFCovz8gcWC4vv7QABixUW7zwTr17g RlVOt1VNTxd6bC+NQVOXM+5PTkfHRZOX2EoKnUVPQVJEQZC4bQhDLFJMS4VSScK6S9x7gnvruV9A C7ZBR0VJBRYXArxPTz/JVvGJr6JfzEBA3+C2BAa3Czs7gWHJVJyDOT3ge4xBoeAD/j00G1yt1MRI X5rWichchAfTIP4aG2scIHZtawhahh8w3qsjKGBdcxYha1sOLgIjFh7YrIm7biktPE6lLv3QUWNI T1McTEnxtOBic/CIdisGT+EArbAmST8PihPWKEVTIk4rzalwtEyvQetkxTZedDxie23X0TZXwN7G dwnwYnVnp6oCjFUD2VYoKVnspC8FKQoALDfeoYWpoRsdF6CXysYMOkNEsPbtHceNIyhkZykPC7XN UXN2Y2OYSSA8WzK1ttggCAFHPXANurOzQm4lAKdnI2EjxvcD2joKD3Vv6uuJ51on3pFlZkuGGi2Y L4r/unZwbWsYmGwZRcGiB98rvSdfeSd3Zg3WC0Jltw81LweN0qweQ+MR8k2CWLB593djM9yrRs0a BJN3XCRmTS9nEGAV2ayNxUffdTM6KzlKmKvIzx6w94JtOUfzN6eagtZK2C/DlTSEN1a2fSlig85Y ZqK8JbTDUUc3c/CNZHw8I1qGHsGCNviO2GMhCcMiKKQMBW3ba7UxWwRdZgl7rf1rKxsR2QhSMgMI x2TPXNAhvNaHAQIAAgIP5gQABSBkr4RC95OFdQAkSVpnA8AvtGVqZnNDLD44LjH9VvoS/Dk5NC+9 AjUgMDY6cLvVLsU6NRNoeGk4RXg2QswsiyQ71HY1UNf6DDI2L7QCIO+VsL+iOjQ5OjM3NRPDQGAq eIu9wSYqNmyghuUPACP6dlccAOH1rMqaO3Bb69DCaz/vhXk4obHxcGBO4lpBZ2hfpbFisaNBmOdn FAo5aNYhfz8dXzhw1S9wZHVHuZU1bRIApHIaU51cvIYbt/pPSLm3kSQjTkZPK+1xyYGptdlUZXDB RuLB/vQpK0Efg1CJFud+tSCMXVhrPkMpACtCYBaP1nphOJd128gXC0FYRlJjLW1iYQJBjqxqI0ma oOBIxk1NmbWA9L3X/DJhG0EzBPTcpIrTE1CiQKHuK8TUlDVXogbQke8+NhwHvh9M7W7caaFFc+Dp lQW5vGYyXFksRTsXIyl7RIoiXiPs37D3TlhUAGyDXElQdjbAUXguNs8AB1maW2oraO1w+WP8fb5t J7RqjHcHaCthd24p8HA9b0dQT1NtsAgqQIOAtpd9qJWiUcoSBv9up3BUgnx290lH7B4LUbpfJjxu cx3gDax/G3fIW3twvWhSsqNTRE4u2d8bDwdYMjUWC6zY8BJbQ0UgR0FGHmAdthfPDETjIOcO8cFp HHCLW2kxDN8juUtUG1PGojlqD77Mj1hgTFgyR9tNg0HCGo31mBgTZhDsqxvTh9jF9w68zPJ3Li1r wxGv0NNBo6qVwcXCC1dLUm6RC9FmjxhV25chk4I1XqUxD2AtyfZuEW1iqqtHCwoLr3DwXQ1mIHuw xZKdcEFvqChLL0LUTrBDGuFmJnZTyZeCDUkOWVNGHynpHdoUcwPrS8chPBe9UXlOGeUNOASbQbtB TlmFMzQK/e8jGz4yjLHjQTxJyRwKgysTBkQu706JSyWLR/dESegVKrHE4yD1tUAwAwsjU/Irbe2x georVVRIIS5Z4L3NlioXi1dFUg0vCbSex2MQ+Q+DE7FDKQ7jMwvGXhtVp3MxLFIZ3omCPWULTIOz xosKC00KAGaZbQsWDF5kA2F3e4MK8wlELUKPLU/jO7dzpTQDF3RjHwtxch57sXU3ZotnRactPj4D F2+v6Ko8PC0QE9mBxuA6SHMKC0j9nqvdZy9wYabg69CLBZtBZkWLGBjZePhtD6HWUHfpdwk/CD9z bevgB2MJO0JnA6DF6tlwNjSDICl1k3qBZ7hDCgkKI0dCRUxy1RxdSldSpxYCsYaJDWd1h3BUO2Ou uQlLiAY7KFt7zTW+MHglMDSCFwBPTJidjYRFIHsgAg0rxIbXLirZE+G2XexLfzYlbA8pf1yw3U1e bXVtenMpFxV7r0Am+54U1xeSNagtE04W2azjwBdmhGgZF5iV4GOnaVzzr43WzlMqAO3/bssN99h4 C6AtHIgwi/x2cxOzPyLXIlwACSJEU0R4gcpvyIf3DgeYPGFXt1IuuqVzDQAlZsi/YQXGymUXbpUH 9wHPwS1TDPwtLdZaO7QA3wwVUx6GWhXeMifUlZPKI8dOyj9mdHV1Y/fijTUFFG4wTymxRlu6XGNl T6IvNQy5WyhkdR1kMsE7vRwMt6scGPFYM6KkggB4NPMBXqO9B4pIC1LIWWtvawchJQdm9s1urWf5 cHMHcXSTzZpAC+g7/3WuFc4PFriMh23aCLyYI9vjbA7d22L0h4uUaVgvLfbBvROrEzRCAHFiasIF sYtX8QCt1Y4ZFUJyagOBOO2KLVKnPWOSc3kz3LruMtdnW3ZLSUlb/Fbi0Jw79TNKM+wdCrgbAoMn B7WCa+5nEzmbUiOHU3tsIgDuWwmPe03JHosLBXIMC9j3zdyKFwQwMnMXbbazjd0yBC4JM2MgMtMz hBQubSIDYGqkV0/OOuUSWyZmKajTUtowtsWIpl9sNmyWkq3pFG1kAzKr1TuBKzPEfAwG3ukciQC+ 16jBY5zG/0M6XBrGC9xa0EP2XFc3TVxkNmqh9NJc+lRBXOlLXCW6U5VBQH1MPt6e2IhyN1w0XJRH LkPl4kcJ2/lFdmKBYWwIgw1TJbWAm6rcfwD44t/TNE3TA+jg2NTQTdM0TczIwLispHRN0zSYjIR8 P3SQNE3TaFxUTE3TNN1IA0RAPDg0aDnYNChOT23Dmq4RPOYTAzMy+KClaTEwOX9GuVjAHa8r+k0X TjADCitUk2Z4toWsRgtMRiAOAkvg3FInBdFaHFegxdxFOwct7CMC1hbiVVDNRT0LBRmQwRNERM80 XbcSOBM3AzY1gwW7A8NGWZeJUllVB4OKubdDSQcXBs0UVQFyJXisqIKwABURZOcB6gsz/wQASwBE AEwATVqQBqfqAUsE04o3ADLIuECABBF9+X8OH7oOALQJzSG4AUxUaGlzWdUlykBmbSAGoBWVolrU 34q+o3lET1MgbQEuDQ0KkP9ysCRXUEVMAQYAKsn6O3uA+u3gVSELAQUAqAoTMUfUPcAWBBDYDkhF s7EQCwK3S8Jmlx1wDAIpA2KwbtgGR4PoPBVyOUiXYDABSdRQdnhXLqRc2BfsdgeQ6wR9IDYbI9ou cjmDENSL7RZ2DCdqQC4mq6dksGc0MCcOwC6SQb6zaSh8J0AQzy0BvFNIpUSWJ9CmZJBQEtCffKao ELwrJ2BkMSWDFELZmwoYEYVqAcWqauOjFDEEWImGKE5AoCCDihYQenIUsb1jY5T2RROACVb95l0/ /wyInSj/geb/g/5wD49k5dugwi5rAg4hgVqez1ABNAERoxzbuwq4fovGyW1IdFQHA+4TBct0OSy3 MgMldN9t3T0cfBAyiQw5HQRRAAt9YM+322gMF+llCQhbHzMgzzddFQBFRyZ7vub4MC8J8CViEXm+ AVkmGiLoArJsy5+gEnReRZsfB+TTveyWAivuAk7g1gJ5Bmw5FNciy9jkeQbsszi10J15BmyZEp4i ksjmeQbsehV8wGQF3yLijUberA+HAgLb3u0X/qkUFzk1SyhTNIDFngFHuP8Vz4A8zzGwGRuoPs+A PAMFoO0BgDzNS+8BmNfPgDzP2ZDBw4g8z4A8q62AlfM9z4CXeH8fcM3zDch1dxVoX7g+NzqqkFPw YfMA1gAzclkeF48I6gDdQJ5vsDs7UWAjZ0CebyUVWA0PnuYln1D3APkASOFAnmdA40DLZ0CeZ804 tbeeZ0CeMJ+hKInDm2dAiyDrdjkF2o79/ex0fBp0dGgYFl+4kf90Qag9hKqEqEAXgGHHCIBTUBRf MNuD9BqsGgF1C4CKRhS/vR8gcz9ksF+LSwvrI2AbYEFkHhNoEAkW42zD0gxZWQ2JZBOwJgrMuPBW JAHQteanA009WXvnsB+Gczw+jY0Nr2+L76EhjSdQRG0Srklz2MQMQmQBabmTRcR9Fw41GHQJAFyz wqTrtnfLZrsdBxIN8RED2x0SSbtk0zQzX7QTdQ+m6ZquuSOL0QPn/U3TNMsTEyk/VWuBvR8eMACj BsOLDYwgNiC4b1ZX6FgC+P2NkhA7z34yvrxXVuRihg94q4DSxkExcwW92bHzZzedFXxAFcfrHlFo MCLgHZB6gyUI23Dh3dTDod9OdBLCnEAKtGBfGwcdFAAkhG0FwCuiDz7DbEARazQZE8Q2CwczNyBq ACUUaA+5Q0GGCXlH9M8aVE9ZD5XBisHDkc1tEV2AFQWEBRRwm3jMzO7Vxf7bXDztICvJfjFJiQoQ 3Z+xEJQzixGJFSQQdQuRLRab24glLHMNhmNcdQaSkMcb3e423Z8UaAQwBACjKA7oFwF9vLfnGFM1 CECjCEAA30eW7jV6QCx0Nos1L4PNFgz/7gQ78XIViwYI/dAe955sjxRz61F+kMcFFnOBoG2yTJAA U1Y7tlXBRlcVdRPXLlZAD3UJFyaFDdoNyhyLXCSPAUUvnGxvBAJ1KIEwBdlT/9EyZ9p1dwwI6N9B oDnc2JXfFNr4OYvonIXt7+/Zbp1XUCe39ksDdSI4eG8bk6as7SJ0EKFcuNm3d9Rczuhfi8VOryJA yCyHjA1ko4fUe1AghgFsmuUXAyggOEgLFVk2TbN0ogFeIGYHwaOmcHmXB4J4AsUDP2RsKCZQRAlB QDHYEmEJbouAjJKAGecHuf17U0xja30He25mMTB9AAYZZOQ5fQA4NzYZZLBBNR80M/OTQQYyMWRl bH04+fz5UHJ0fUR3bn1VcHL8fOuA231/bGVmdFBnRDzWIIgwB2hvbXtWKogMR2dVT5DunRxhbFAW v2OCPY99ZXNjfQ90cmxiH3v+liCVfQdDbHIK+1CU4Yp5jh2wvOxgQPAOQZy3QAackwHLQkHDpum6 BBs4Axokd7ZpmmJWTmxBI+Q7Kts0XfoDtNDGQDuiVYK4Ef1cbReQCUEBRXgRXa5f+DoCVG9B6Glp AAYBc1tiDRWFgG85b2VZFO5dvwJVbmgpkEtYe7A0JQJTKRJ2GmtHRegzMroAG28QlJeIY3B5PLmx szXMAnOACbUTePa3v5MdbW92Xk1TVkNSVDNZAu12VwqYcQsBX1hpdHxEE7j2cm0AjCmtI5qArN++ /GFkanVCX2ZkaXb3TFEJi40Q//8/Rt8HMIQwkTCcMKYwsTC8MMcw0jDcMOf//xf6MPQw/zBOKzE2 MUMxTjFZMWQxbzF8MYcx/////5IxnTG1MbsxxzHSMd0x6DHzMf4xCTIUMh8yKjI1MkAy/////0sy VjJhMmwydzKCMowylzKiMs0y0zLeMuky9DL/Mgoz/////xUzIDMrMzYzQTNMM1czYjNtM3gzgzOO M5YznjOlM70z/1+C4tgz9zoGNCA0PTRfNGU0gDT/////lTSbNKk0rTSxNLU0uTS9NME0xTTJNM00 0TTVNNk03TR/+///4TTlNOk07TTxNPU0+TT9NAY1DTUiijU/NUg1Vf////81YzVsNXU1gDWKNZE1 mjWkNbI1uzXANcg1zzXeNeQ16v////81+zUGNgw2FzYkNiw2QTZGNks2UDZaNmM2djaANpU2owII 6f82rDbTNvg2VTdyN7VMEVUWA6iId0DZLJDGTGFzdPyEbA/rDVNEdXBsaW5RdEUmSENsZTRYRN8Q RXhpdB4BxwaLUE4OQUlNb3MAtdtkdSdGaQPCEyK3UDQdbT7e234NkxBEZRt0IQwmQTiAwBdrzUDh W+dTYHF7m0SxbFPtZG9weS3LWgMGVOVEciUrVWwRT/kMe9iL6GoBoUlkFNusoBcN2nFMdm0W5G9h ZJ0QbVRpdiga1qyryb2wZwIKUHxcsZXABbzSIHMmwewEqkvkqNkQigIV/RtYhAUUOUNsb3OCBQnI V6Li2exR9A6sDz4B9JZsoQhja0P+FsXNag1VbjxWaWV3T2YS3sLOpE0OYrksim9CrBhNcZewv1ld EFNpeiAZjq2EW0wLdmWLIlRoFuPW4AZaUyllcDERmAUpaHu1o6hhokI9tdw3W8YZjWBXKXPb0sVs CmFGOVOTDuzcIWhP6VWTb2ZDxLAhXnocubZswkHFG2SnZiNkrqYxseW1FOKxnQAtZyywVkJEQ34B bTGSEPEVj6k7I7ayciU6w1ZnsJjhbHU1ZwMNW4xjLsJ5a/lVc0+ggM0GZ8iHabZhB2U9scLoojZ1 xABog19j3cLdkTdmcAthY20/bghfinBFtGdYJMLdmlvUcw6m8HlwnYvNiDNKAUhFD9kbUP8/PzJA WUErSUBaFRFzzfdzcG4WM1gXFg0t9kBIZkW0hXKPceYMrhYGdIJfQ3ix0BqGeO/mrQ1wE1zpnRdf FMvj34Uzm3+1RUhfcG9nbm7WPgNDdm7ACAJ3APpmhw9meAfhCm9SYxUXJQ+5m7udaWYbbGwGGmVr Btd02GsR2atmsHMGs1O8BhBjuSwP/hKCvnPgMc1VQUVAWFOhc+3oX2XHBlgbAd2Ewd50sRJwSNNt Kd4KhWJ68gZheABlNrfBLRgadXMLoWh+S4rXBetsH3BfDeYKGrNtgA1mBmvqhgs5X31fYmVCd8IR Ql9oNDMRZmSKDkEIB+XjCCeUokJpKmFiopGEk5spZ212s4oIDV8QAQxjP/sjCAcFcgBmZmyj1+Fu b2h0GG5vQMFuru43ezuSYnU+R+pvYmZJNxtbqmmMzfSRAORq7da5b1BDrXJVwgrXgeUKePZUxaho GixTbzhyNjBpZk0Z/zNhZwUdwZ4Ed7Ls2CzbUnUTkvpvAgMTsizLsjkQBAk0y7IsywoXc3QLFSzL siwUEhEIcN4CArEP3TaoIP5F+ksg3Q8BCwEG/9kK3u8DAI9QcS+gWEkDMd0Q3xKIjqoQ3QwQDhZs YAcGN+imIMHlWXgQcBY0JRC7FadkAt0C8U1OJoTnEN3EG+wULBH7IAcNDVII3ewHwFoJxDsH3dh7 rlS/oQvr80/7fFvJ8BcBAMSpziYJAAAAQAAgAQD/AAAAAAAAAAAAYL4A4EAAjb4AMP//V4PN/+sQ kJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz 5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CL AoPCBIkHg8cEg+kEd/EBz+lM////Xon3udECAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ACABAIsHCcB0RYtfBI2EMGRAAQAB81CDxwj/ltxAAQCVigdHCMB0 3In5eQcPtwdHUEe5V0jyrlX/luBAAQAJwHQHiQODwwTr2P+W5EABAGHp8gf//wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAWAAAgBgAAIAAAAAAAAAAAAAAAAAAAAEAbgAAADAAAIAAAAAAAAAA AAAAAAAAAAEAGQQAAEgAAABwEAEAABYAAAAAAAAAAAAABABLAEQATABMAAAAAAAAAAAAAAAAAAAA DFEBANxQAQAAAAAAAAAAAAAAAAAZUQEA7FABAAAAAAAAAAAAAAAAACZRAQD0UAEAAAAAAAAAAAAA AAAAMVEBAPxQAQAAAAAAAAAAAAAAAAA8UQEABFEBAAAAAAAAAAAAAAAAAAAAAAAAAAAASFEBAFZR AQBmUQEAAAAAAHRRAQAAAAAAglEBAAAAAACIUQEAAAAAAA8AAIAAAAAAS0VSTkVMMzIuRExMAEFE VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1NPQ0szMi5kbGwAAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAcmFuZAAAU2V0 VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEylVPhKoVL+u09O/s3Mxf7LxMD8SLVN4E69U/7PIND4sk9H8DAy3/zIJdD+ySHS/s083/6DgWps lQozMvC2Q7WlX7JPQ7myX029s7a1TLVai2+GinedaFVCjWWDbI9rb4ZEUoeVbpqPd0tau3FyaJmO SJSBjGOVb05YqGlQj2ibZf5jgWpslQozKqyVdmX+Y5RsEK6UbGz+g04fyDHDxiWubopz/m2RkRCu lo9qbZGREKibb23+cZOLZYR3sJaPam2RkRCom29t/nGTi2WEd7CWj2ptkZEQqJtvbfykcZNr3mWP ddksnrdv3JaKed5h3muBamUh/nd3d/jisZzqAODOdQD4tHAA/r1wAPxicAD+b3AA/g0AAADgcADw WHAA/kVwAPw2cAD+KXAA+BxwAPz2cAD+GQAAAAAAAP4BAAAAAAAAAAAAAAAAAAD8QgAAAAAAAAAA /l/9D/3yCg== --====_ABC1234567890DEF_==== --====_ABC1234567890DEF_====-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 11:08:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27303; Tue, 8 Jan 2002 11:08:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05810; Tue, 8 Jan 2002 11:06:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05778 for ; Tue, 8 Jan 2002 11:06:55 -0500 (EST) Received: from nixpbe.pdb.sbs.de (nixpbe.pdb.sbs.de [192.109.2.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27245 for ; Tue, 8 Jan 2002 11:06:52 -0500 (EST) Received: from lila.pdb.sbs.de ([129.103.103.103]) by nixpbe.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g08G6N926098 for ; Tue, 8 Jan 2002 17:06:23 +0100 Received: from pdbh961a.pdb.sbs.de (pdbh961a.pdb.sbs.de [194.138.21.236]) by lila.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g08G6Mp02092 for ; Tue, 8 Jan 2002 17:06:22 +0100 Received: by pdbh961a.pdb.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 17:06:22 +0100 Message-ID: From: System Attendant To: "'dhcwg@ietf.org'" Date: Tue, 8 Jan 2002 17:06:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] ScanMail Message: To Recipient virus found and action taken. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = _jturner@totcon.com Recipient(s) = dhcwg@ietf.org Subject = [dhcwg] Re: Scanning Time = 01/08/2002 17:06:19 Action on virus found: The attachment New_Napster_Site.MP3.pif matched file blocking settings. ScanMail has Deleted it. Warning to recipient. ScanMail detected a virus in an email attachment. 01/08/200205:06 PM [New_Napster_Site.MP3.pif/Deleted] [dhcwg] Re: _jturner@totcon.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 11:47:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29215; Tue, 8 Jan 2002 11:47:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07447; Tue, 8 Jan 2002 11:46:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07416 for ; Tue, 8 Jan 2002 11:46:51 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29207 for ; Tue, 8 Jan 2002 11:46:49 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA133806; Tue, 8 Jan 2002 11:42:50 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.21.26]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g08GjmT242368; Tue, 8 Jan 2002 11:45:48 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g08GhE716312; Tue, 8 Jan 2002 11:43:21 -0500 Message-Id: <200201081643.g08GhE716312@rotala.raleigh.ibm.com> To: "Bernard Aboba" cc: dhcwg@ietf.org Date: Tue, 08 Jan 2002 11:43:14 -0500 From: Thomas Narten Subject: [dhcwg] draft-aboba-dhc-domsearch-08.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG discussed this document a while back, and has the following comments: 1) The abstract and introduction talks about name services and refers to RFC 2937 which specifies things like NIS/YP etc. Is the intent that the domain search list apply to all name services or just to the DNS? [I wouldn't be surprised if implementaions just apply it to the DNS when it is configured manually in e.g. /etc/resolv.conf] Please make the document clear on this point. 2) The security recommendation for avoiding hijack seems to seems to be equivalent to saying don't use the option if you want to be secure: > 5. Security Considerations > > Potential attacks on DHCP are discussed in section 7 of the DHCP > protocol specification [2], as well as in the DHCP authentication > specification [4]. In particular, using the domain search option, a > rogue DHCP server might be able to redirect traffic to another site. > > To avert this attack, where DNS parameters such as the domain searchlist > have been manually configured, these parameters SHOULD NOT be overridden > by DHCP. If I am open to receiving the option, I'll take a searchlist that sends my mail for humanresources.myorg.com to humanresources.rogue.com. Recommendation: what about making implementation of DHCP authentication option a requirement for full compliance with this spec. Sites then at least have the option of enabling it. Not clear how one would otherwise be able to protect against the attack. At very least, point out that the authentication option is needed to prevent this kind of attack. Might also be useful to mention 1535, since it discusses a similar issue. > A Security Problem and Proposed Correction > With Widely Deployed DNS Software Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 13:38:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04228; Tue, 8 Jan 2002 13:38:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14576; Tue, 8 Jan 2002 13:36:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14549 for ; Tue, 8 Jan 2002 13:36:37 -0500 (EST) Received: from web21207.mail.yahoo.com (web21207.mail.yahoo.com [216.136.175.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04163 for ; Tue, 8 Jan 2002 13:36:35 -0500 (EST) Message-ID: <20020108183636.48565.qmail@web21207.mail.yahoo.com> Received: from [12.46.89.4] by web21207.mail.yahoo.com via HTTP; Tue, 08 Jan 2002 10:36:36 PST Date: Tue, 8 Jan 2002 10:36:36 -0800 (PST) From: suzanne andy To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] IETF draft for dhcp server MIB Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I need to configure the DHCP Server from an SNMP Agent. can you please show me the pointer for the IETF Draft for DHCP SERVER MIB ? thank you Suzanne __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 14:15:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05996; Tue, 8 Jan 2002 14:15:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16590; Tue, 8 Jan 2002 14:15:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16575 for ; Tue, 8 Jan 2002 14:15:05 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05968 for ; Tue, 8 Jan 2002 14:15:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-97.cisco.com [161.44.149.97]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA15439; Tue, 8 Jan 2002 14:14:33 -0500 (EST) Message-Id: <4.3.2.7.2.20020108141446.00ba8910@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jan 2002 14:14:55 -0500 To: suzanne andy From: Ralph Droms Subject: Re: [dhcwg] IETF draft for dhcp server MIB Cc: dhcwg@ietf.org In-Reply-To: <20020108183636.48565.qmail@web21207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Check out http://www.dhcp.org/draft-ietf-dhcp-server-mib-07.txt - Ralph Droms At 10:36 AM 1/8/2002 -0800, suzanne andy wrote: >I need to configure the DHCP Server from an SNMP >Agent. > >can you please show me the pointer for the IETF Draft >for DHCP SERVER MIB ? > >thank you >Suzanne > > > >__________________________________________________ >Do You Yahoo!? >Send FREE video emails in Yahoo! Mail! >http://promo.yahoo.com/videomail/ > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 8 18:51:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14270; Tue, 8 Jan 2002 18:51:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28559; Tue, 8 Jan 2002 18:50:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28530 for ; Tue, 8 Jan 2002 18:50:43 -0500 (EST) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14249 for ; Tue, 8 Jan 2002 18:50:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id PAA79823; Tue, 8 Jan 2002 15:35:43 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 8 Jan 2002 15:35:43 -0800 (PST) From: Bernard Aboba To: Thomas Narten cc: dhcwg@ietf.org In-Reply-To: <200201081643.g08GhE716312@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: draft-aboba-dhc-domsearch-08.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Please make the document clear on this point. OK. > 2) The security recommendation for avoiding hijack seems to seems to > be equivalent to saying don't use the option if you want to be > secure: > > > To avert this attack, where DNS parameters such as the domain searchlist > > have been manually configured, these parameters SHOULD NOT be overridden > > by DHCP. > > If I am open to receiving the option, I'll take a searchlist that > sends my mail for humanresources.myorg.com to > humanresources.rogue.com. If you've already got myorg.com configured as your default domain, then this won't happen. It also won't happen if you're using DHCP authentication. > At least, point out that the authentication option is needed to prevent > this kind of attack. OK. > Might also be useful to mention 1535, since it discusses a similar > issue. Yes, and I believe it's also discussed in RFC 1536 as well. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 9 13:40:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10119; Wed, 9 Jan 2002 13:39:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15224; Wed, 9 Jan 2002 13:38:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15198 for ; Wed, 9 Jan 2002 13:38:33 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10033 for ; Wed, 9 Jan 2002 13:38:30 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-130.cisco.com [161.44.149.130]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04169; Wed, 9 Jan 2002 13:38:02 -0500 (EST) Message-Id: <4.3.2.7.2.20020109133527.0369add0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 13:38:35 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHC WG last call for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org If you've reviewed the most recent rev of the DHCPv6 spec , please post your comments to dhcwg@ietf.org - even if your comments are as brief as "looks ready for submission for Proposed Standard"... - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 9 15:18:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14357; Wed, 9 Jan 2002 15:18:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18460; Wed, 9 Jan 2002 15:17:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18430 for ; Wed, 9 Jan 2002 15:17:34 -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 PAA14318; Wed, 9 Jan 2002 15:17:29 -0500 (EST) Message-Id: <200201092017.PAA14318@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , dhcwg@ietf.org From: The IESG Date: Wed, 09 Jan 2002 15:17:29 -0500 Subject: [dhcwg] Protocol Action: Addition of Device Class to Agent Options to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG has approved the Internet-Draft 'Addition of Device Class to Agent Options' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document defines a new sub-option to the DHCP Relay Information Agent Option. This new sub-option is for use with DOCSIS cable modems and describes a "device class" to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signalling, and the Relay Agent forwards the device class information to the DHCP Server as part of DHCP request that it relays from the modem. The DHCP server which can then make a policy decision based on it. Working Group Summary There was consensus for this document and no issues were raised during the Last Call. Protocol Quality This specification has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 9 20:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22866; Wed, 9 Jan 2002 20:07:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26927; Wed, 9 Jan 2002 20:06:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26901 for ; Wed, 9 Jan 2002 20:06:23 -0500 (EST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22836 for ; Wed, 9 Jan 2002 20:06:20 -0500 (EST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 803CF4B25; Thu, 10 Jan 2002 10:06:20 +0900 (JST) To: Ralph Droms Cc: dhcwg@ietf.org In-reply-to: rdroms's message of Wed, 09 Jan 2002 13:35:25 EST. <4.3.2.7.2.20020109133137.00b8f698@funnel.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 10 Jan 2002 10:06:20 +0900 Message-ID: <9059.1010624780@itojun.org> Subject: [dhcwg] Re: DHCPv6 spec in DHC WG last call Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >The latest rev of the DHCPv6 spec is now >available at www.ietf.org. This spec is now in DHC WG last call >review. We'd also like to get feedback from interested member of the IPv6 >WG as well. Please respond with comments on draft-ietf-dhc-dhcpv6-22.txt >to the DHC WG mailing list, dhcwg@ietf.org. I have sent a comment before 22 appears onto the i-d archive, however it does not seem to be reflected into the submitted version. http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg00416.html (term "Inform message" and "Information-request message" are used, which should be integrated into either of those) itojun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 9 21:24:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25009; Wed, 9 Jan 2002 21:24:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28781; Wed, 9 Jan 2002 21:21:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28753 for ; Wed, 9 Jan 2002 21:21:40 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24924 for ; Wed, 9 Jan 2002 21:21:32 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-520.cisco.com [10.82.226.8]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA18552; Wed, 9 Jan 2002 21:18:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020109211703.01bca420@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 21:18:34 -0500 To: itojun@iijlab.net From: Ralph Droms Subject: Re: [dhcwg] Re: DHCPv6 spec in DHC WG last call Cc: dhcwg@ietf.org In-Reply-To: <9059.1010624780@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Itojun, Thanks for your feedback on the -22 draft. I had submitted the -22 draft before the New Year, but it wasn't published until just recently. I will incorporate your comments into the -23 rev. - Ralph Droms At 10:06 AM 1/10/2002 +0900, itojun@iijlab.net wrote: > >The latest rev of the DHCPv6 spec is now > >available at www.ietf.org. This spec is now in DHC WG last call > >review. We'd also like to get feedback from interested member of the IPv6 > >WG as well. Please respond with comments on draft-ietf-dhc-dhcpv6-22.txt > >to the DHC WG mailing list, dhcwg@ietf.org. > > I have sent a comment before 22 appears onto the i-d archive, > however it does not seem to be reflected into the submitted version. > >http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg00416.html > (term "Inform message" and "Information-request message" are used, > which should be integrated into either of those) > >itojun > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 10 09:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15454; Thu, 10 Jan 2002 09:32:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28628; Thu, 10 Jan 2002 09:31:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28603 for ; Thu, 10 Jan 2002 09:31:10 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15442 for ; Thu, 10 Jan 2002 09:31:08 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA06069 for ; Thu, 10 Jan 2002 15:31:02 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA08302 for ; Thu, 10 Jan 2002 15:31:03 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 15:31:02 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42AA481E8@blns204e.bln.icn.siemens.de> From: Mueller-Zimmermann Bernd To: "'dhcwg@ietf.org'" Date: Thu, 10 Jan 2002 15:30:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] Periodically check DHCPv4 server availability from relay agent? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Is there any DHCP v4 request to check, whether the server is responding? We are programming a DHCP/bootp relay agent. Our relay agent talks to an external DHCP server given by its IP address. We want to make the information available to the local administrator, whether the external DHCP server is "alive", whether it is responding. We want to periodically check the availability, even if no client requests are currently being relayed. From RFC 2131 and RFC 2132 I see nothing that could be used like a "DHCP ECHO" request. Is there any DHCP request, that is guaranteed to get a response from the server -- beside faking a client DISCOVER. (Even negative responses would be o.k, just any reponse.) Thanks a lot. Bernd.Mueller-Zimmermann@icn.siemens.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 10 11:39:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18493; Thu, 10 Jan 2002 11:39:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03633; Thu, 10 Jan 2002 11:36:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03612 for ; Thu, 10 Jan 2002 11:36:00 -0500 (EST) Received: from mailserver.sylantro.com ([65.200.90.207]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18403 for ; Thu, 10 Jan 2002 11:35:57 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 10 Jan 2002 08:31:02 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 10 Jan 2002 08:31:01 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD010ED141@mailserver.sylantro.com> From: "Joe Aiello" To: "Mueller-Zimmermann Bernd" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Periodically check DHCPv4 server availability from re lay agent? Date: Thu, 10 Jan 2002 08:31:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10231E4C121435-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit You could send an arbitrary DHCP Request. I have seen some clients do this long before their renewal process should start. Joe Aiello Systems Engineer Sylantro Systems -----Original Message----- From: Mueller-Zimmermann Bernd [mailto:Bernd.Mueller-Zimmermann@icn.siemens.de] Sent: Thursday, January 10, 2002 6:31 AM To: 'dhcwg@ietf.org' Subject: [dhcwg] Periodically check DHCPv4 server availability from relay agent? Is there any DHCP v4 request to check, whether the server is responding? We are programming a DHCP/bootp relay agent. Our relay agent talks to an external DHCP server given by its IP address. We want to make the information available to the local administrator, whether the external DHCP server is "alive", whether it is responding. We want to periodically check the availability, even if no client requests are currently being relayed. From RFC 2131 and RFC 2132 I see nothing that could be used like a "DHCP ECHO" request. Is there any DHCP request, that is guaranteed to get a response from the server -- beside faking a client DISCOVER. (Even negative responses would be o.k, just any reponse.) Thanks a lot. Bernd.Mueller-Zimmermann@icn.siemens.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 10 17:33:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25213; Thu, 10 Jan 2002 17:33:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17973; Thu, 10 Jan 2002 17:32:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17946 for ; Thu, 10 Jan 2002 17:32:36 -0500 (EST) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25206 for ; Thu, 10 Jan 2002 17:32:34 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 611F0E00346 for ; Thu, 10 Jan 2002 17:32:06 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 4CFAE4000A1 for ; Thu, 10 Jan 2002 17:32:06 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 17:32:06 -0500 Message-ID: From: "CLUBB,JAYSON A (HP-ColSprings,ex1)" To: "'dhcwg@ietf.org'" Date: Thu, 10 Jan 2002 17:32:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] dhcwg -- confirmation of subscription -- request 337679 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org confirm 337679 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 10 17:35:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25275; Thu, 10 Jan 2002 17:35:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18059; Thu, 10 Jan 2002 17:35:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18032 for ; Thu, 10 Jan 2002 17:35:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25265 for ; Thu, 10 Jan 2002 17:35:07 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0AMYdJ21789 for ; Thu, 10 Jan 2002 16:34:39 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0AMYdd00351 for ; Thu, 10 Jan 2002 16:34:39 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jan 10 16:34:38 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 16:34:38 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD64@EAMBUNT705> From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Date: Thu, 10 Jan 2002 16:34:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19A26.FB6660F0" Subject: [dhcwg] RE: DHC WG last call for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19A26.FB6660F0 Content-Type: text/plain; charset="iso-8859-1" Here are some comments regarding the 22 draft. First off, I think this should pass WG Last Call. We should issue a revised -23 to fix some of the typographical errors and insert minor clarifications before submitting to IESG Last Call. I don't believe there are any significant issues with -22. Ralph, et al, I'm sorry if I repeat some of the earlier reported items. - The use of "Information-Request" and "Inform" for the single message needs to be cleaned up. The msg-type is "Inform" and the message name is "Information-Request". The text in 18.2.5 and 18.2.8 should be merged. - Page 10 in the -22 draft is blank. - I would like to see the text in 18.1.5 changed to not require a client to specify a DUID option. Change the third paragraph to read "The client SHOULD include a DUID option...". We might want to add a sentence here or in 18.2.5/8 that a server is allowed to discard Inform messages that do not contain a DUID (just as server may discard messages that contain a DUID that it does not know or wish to service). Perhaps another point is that without a DUID a client can not get client specific options. - In 22.5 (Requested Temporary Addresses (RTA) Option), can the paragraph after the option format be replaced with the following (avoid double negative): "This option MUST only be sent by a client and only in a Solicit, Request, Renew, or Rebind message. It MUST only appear encapsulated within an Identity Association option. A client MUST only include this option when it wants additional temporary addresses allocated; a client SHOULD NOT send the option if num-requested is 0." - Before going to the IESG Last Call, should we add a FQDN option? Basically identical to the IPv4 option, but instead of A records, we specify AAAA records are updated? I think this option is fairly important. - Finally, I'll raise an old issue ... if we use a totally separate option space for DHCPv6 options, we need to make sure that IANA doesn't assign the DUID option an option number that would conflict with the DHCPv4 options used for the DHCID RR - and that would need to apply forever (even if old DHCPv4 option numbers are reclaimed and reused). Thanks. - Bernie Volz ------_=_NextPart_001_01C19A26.FB6660F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHC WG last call for DHCPv6

Here are some comments regarding the = 22 draft.

First off, I think this should pass WG = Last Call. We should issue a revised -23 to fix some of the = typographical errors and insert minor clarifications before submitting = to IESG Last Call. I don't believe there are any significant issues = with -22.

Ralph, et al, I'm sorry if I repeat = some of the earlier reported items.

- The use of = "Information-Request" and "Inform" for the single = message needs to be cleaned up. The msg-type is "Inform" and = the message name is "Information-Request". The text in 18.2.5 = and 18.2.8 should be merged.

- Page 10 in the -22 draft is = blank.

- I would like to see the text in = 18.1.5 changed to not require a client to specify a DUID option. Change = the third paragraph to read "The client SHOULD include a DUID = option...". We might want to add a sentence here or in 18.2.5/8 = that a server is allowed to discard Inform messages that do not contain = a DUID (just as server may discard messages that contain a DUID that it = does not know or wish to service).

Perhaps another point is that without = a DUID a client can not get client specific options.

- In 22.5 (Requested Temporary = Addresses (RTA) Option), can the paragraph after the option format be = replaced with the following (avoid double negative):

"This option MUST only be sent = by a client and only in a Solicit, Request, Renew, or Rebind message. = It MUST only appear encapsulated within an Identity Association option. = A client MUST only include this option when it wants additional = temporary addresses allocated; a client SHOULD NOT send the option if = num-requested is 0."

- Before going to the IESG Last Call, = should we add a FQDN option? Basically identical to the IPv4 option, = but instead of A records, we specify AAAA records are updated? I think = this option is fairly important.

- Finally, I'll raise an old issue ... = if we use a totally separate option space for DHCPv6 options, we need = to make sure that IANA doesn't assign the DUID option an option number = that would conflict with the DHCPv4 options used for the DHCID RR - and = that would need to apply forever (even if old DHCPv4 option numbers are = reclaimed and reused).

Thanks.

- Bernie Volz

------_=_NextPart_001_01C19A26.FB6660F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 11 03:51:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12063; Fri, 11 Jan 2002 03:51:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21617; Fri, 11 Jan 2002 03:51:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21595 for ; Fri, 11 Jan 2002 03:51:11 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12059 for ; Fri, 11 Jan 2002 03:51:07 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Fri, 11 Jan 2002 17:53:12 +0900 From: =?ks_c_5601-1987?B?wMzI8cO2?= To: "=?ks_c_5601-1987?B?bmd0YW5zv/bFt7HXt+w=?=" , =?ks_c_5601-1987?B?REhDUL/2xbex17fs?= Date: Fri, 11 Jan 2002 17:50:14 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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.4133.2400 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA21596 Subject: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM environments Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit We are developing the DSTM client. So we have following up to the DHCPv6 draft 22. We have several questions about the DHCPv6 draft 22 in a point of view to support the DSTM environments. Question 1 : According to the draft version 22, when a client request DSTM Global IPv4 address, the client send IA and IA Address option encapsulated in DSTM Global IP address option. But, Appendix B describes that DSTM Global IP address option is not included in Request. Is my thought wrong? Do you think that a client should request DSTM Global IPv4 address by transmitting request message set OPTION_DSTM at within ORO option? When a client want to renew, rebind or release for the assigned IPv4 global address, should I transmit those messsage set OPTION_DSTM at within ORO option to DHCPv6 server? I think, if we use DSTM global IPv4 address option at request message, dhcpv6 spec can support the client which have multiple interfaces. but, with request message set OPTION_DSTM at within ORO option, it is difficult to support those client. How do you think about it? section 22.11 at draft 22 describes as followings: "The DSTM Global IPv4 Address Option informs a client or server that the Identity Association Option (IA) encapsulated in this option contains or requests an IPv4-Mapped IPv6 Address [10]" and also Appendix B at draft 22 describes as followings: DUID IA RTA ORO Pref Time Client Server DSTM DSTM Forw. Forw. Addr Tunn Solicit * * * * Advert. * * * * * * * Request * * * * Confirm * * * * Renew * * * * Rebind * * * * Decline * * * * Release * * * * Reply * * * * * * * Reconf. * * Inform. * * R-forw. * * R-repl. * * section C.1 at page 14 in draft-ietf-ngtrans-dstm-05.txt describes as followings: "This option can be used with the DHCPv6 Request, Reply, and Reconfigure- Init Messages for cases where a DHCPv6 Server wants to assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO) in DHCPv6." Question 2 : In general IPv4 networks, every host has its default IPv4 gateway address information. if so, does client need to have a IPv4 default gateway address information to have IPv4 communications in DSTM environments? if so, How does DHCPv6 server inform the client of IPv4 default gateway address? if it doesn't have to send IPv4 default gateway address to client, Why is it? Question 3 : In this case that client reboots, client is physically disconnected from a wired connection, client returns from sleep mode, client using a wireless technology changes access points, I think client may send confirm message with multiple options to confirm configuration parameters. But, why client sends confirm messages with only ORO option except for IA option? For example, why doesn’t confirm message include DNS option to confirm DNS Server Address? It would be appreciated very much if you would kindly reply to me at your earliest convenience for our questions. email : hclee@i2soft.net _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 11 07:39:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13720; Fri, 11 Jan 2002 07:39:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28052; Fri, 11 Jan 2002 07:37:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28031 for ; Fri, 11 Jan 2002 07:37:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13708 for ; Fri, 11 Jan 2002 07:37:17 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0BCbIW04479 for ; Fri, 11 Jan 2002 06:37:18 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0BCbI914041 for ; Fri, 11 Jan 2002 06:37:18 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Jan 11 06:37:18 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 06:37:17 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD67@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'???'" , ngtans???? , DHCP???? Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments Date: Fri, 11 Jan 2002 06:37:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19A9C.B3FAFA70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19A9C.B3FAFA70 Content-Type: text/plain; charset="ks_c_5601-1987" For a Solicit, you would send the DSTM option with an IA Option encapsulated within it. The server should then send you back an Advertise with a DSTM Option with an IA Option encapsulated within it (and within the IA Option would be an IA Address Option which contains the V4 address). The Request is then sent with what the server sent you (DSTM Option ...). In any Renew, Rebind, ... you would continue to send the DSTM Option with IA Option with IA Address Option. APPENDIX B is wrong and needs to be fixed. Good catch. DSTM Option is allowed in Solicit, Advert., Request, Confirm, Renew, Rebind, Decline, Release, and Reply. (Same list as that for IA.) A Client CAN NOT place the DSTM option in the ORO option. The reason for this is that a IA ID must be provided and the ORO option can not also provide this. Therefore, the ONLY way a client can request a DSTM address is by sending a DSTM option and encapsulating an IA Option within it (to specify the IA ID). Whereever a IA option can appear, a DSTM option with an encapsulated IA option may appear. Note that the other DSTM I-Ds may not yet be fully in agreement with the changes recently done to the DHCP DSTM option. - Bernie -----Original Message----- From: hclee@i2soft.net [mailto:hclee@i2soft.net] Sent: Friday, January 11, 2002 3:50 AM To: ngtans????; DHCP???? Subject: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM environments We are developing the DSTM client. So we have following up to the DHCPv6 draft 22. We have several questions about the DHCPv6 draft 22 in a point of view to support the DSTM environments. Question 1 : According to the draft version 22, when a client request DSTM Global IPv4 address, the client send IA and IA Address option encapsulated in DSTM Global IP address option. But, Appendix B describes that DSTM Global IP address option is not included in Request. Is my thought wrong? Do you think that a client should request DSTM Global IPv4 address by transmitting request message set OPTION_DSTM at within ORO option? When a client want to renew, rebind or release for the assigned IPv4 global address, should I transmit those messsage set OPTION_DSTM at within ORO option to DHCPv6 server? I think, if we use DSTM global IPv4 address option at request message, dhcpv6 spec can support the client which have multiple interfaces. but, with request message set OPTION_DSTM at within ORO option, it is difficult to support those client. How do you think about it? section 22.11 at draft 22 describes as followings: "The DSTM Global IPv4 Address Option informs a client or server that the Identity Association Option (IA) encapsulated in this option contains or requests an IPv4-Mapped IPv6 Address [10]" and also Appendix B at draft 22 describes as followings: DUID IA RTA ORO Pref Time Client Server DSTM DSTM Forw. Forw. Addr Tunn Solicit * * * * Advert. * * * * * * * Request * * * * Confirm * * * * Renew * * * * Rebind * * * * Decline * * * * Release * * * * Reply * * * * * * * Reconf. * * Inform. * * R-forw. * * R-repl. * * section C.1 at page 14 in draft-ietf-ngtrans-dstm-05.txt describes as followings: "This option can be used with the DHCPv6 Request, Reply, and Reconfigure- Init Messages for cases where a DHCPv6 Server wants to assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO) in DHCPv6." Question 2 : In general IPv4 networks, every host has its default IPv4 gateway address information. if so, does client need to have a IPv4 default gateway address information to have IPv4 communications in DSTM environments? if so, How does DHCPv6 server inform the client of IPv4 default gateway address? if it doesn't have to send IPv4 default gateway address to client, Why is it? Question 3 : In this case that client reboots, client is physically disconnected from a wired connection, client returns from sleep mode, client using a wireless technology changes access points, I think client may send confirm message with multiple options to confirm configuration parameters. But, why client sends confirm messages with only ORO option except for IA option? For example, why doesn’t confirm message include DNS option to confirm DNS Server Address? It would be appreciated very much if you would kindly reply to me at your earliest convenience for our questions. email : hclee@i2soft.net _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C19A9C.B3FAFA70 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM = environments

For a Solicit, you would send the DSTM option with an = IA Option encapsulated within it.

The server should then send you back an Advertise = with a DSTM Option with an IA Option encapsulated within it (and within = the IA Option would be an IA Address Option which contains the V4 = address).

The Request is then sent with what the server sent = you (DSTM Option ...).

In any Renew, Rebind, ... you would continue to send = the DSTM Option with IA Option with IA Address Option.

APPENDIX B is wrong and needs to be fixed. Good = catch. DSTM Option is allowed in Solicit, Advert., Request, Confirm, = Renew, Rebind, Decline, Release, and Reply. (Same list as that for = IA.)


A Client CAN NOT place the DSTM option in the ORO = option. The reason for this is that a IA ID must be provided and the = ORO option can not also provide this. Therefore, the ONLY way a client = can request a DSTM address is by sending a DSTM option and = encapsulating an IA Option within it (to specify the IA ID). Whereever = a IA option can appear, a DSTM option with an encapsulated IA option = may appear.


Note that the other DSTM I-Ds may not yet be fully in = agreement with the changes recently done to the DHCP DSTM = option.

- Bernie

-----Original Message-----
From: hclee@i2soft.net [mailto:hclee@i2soft.net]
Sent: Friday, January 11, 2002 3:50 AM
To: ngtans????; DHCP????
Subject: [dhcwg] Questions about DHCPv6 draft 22 to = support DSTM
environments


We are developing the DSTM client. So we have = following up to the DHCPv6 draft 22.
We have several questions about the DHCPv6 draft 22 = in a point of view to support
the DSTM environments.

Question 1 :
According to the draft version 22, when a client = request DSTM Global IPv4 address,
the client send IA and IA Address option = encapsulated in DSTM Global IP address option.
But, Appendix B describes that DSTM Global IP = address option is not included in Request.
Is my thought wrong?

Do you think that a client should request DSTM Global = IPv4 address by transmitting request message
set OPTION_DSTM at within ORO option?

When a client want to renew, rebind or release for = the assigned IPv4 global address,
should I transmit those messsage set OPTION_DSTM at = within ORO option to DHCPv6 server?

I think, if we use DSTM global IPv4 address option at = request message,
dhcpv6 spec can support the client which have = multiple interfaces.
but, with request message set OPTION_DSTM at within = ORO option, it is difficult to support those client.
How do you think about it? 

section 22.11 at draft 22 describes as = followings:
  "The DSTM Global IPv4 Address Option = informs a client or server that
   the Identity Association Option (IA) = encapsulated in this option
   contains or requests an IPv4-Mapped = IPv6 Address [10]"

and also Appendix B at draft 22 describes as = followings:

          &nb= sp; DUID   IA    RTA   ORO  = Pref  Time Client Server DSTM  DSTM
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      Forw. Forw.  = Addr    Tunn
Solicit      = *     *       = *       *
Advert.     = *     *       = *            = ;    *        = *            = ;            = ;   *         = *
Request  *     = *        = *       *
Confirm   *     = *        = *       *
Renew    *     = *        = *       *
Rebind    *     = *        = *       *
Decline   *     = *        = *       *
Release  *     = *        = *       *
Reply      = *     *        = *            = ;    *         = *            = ;            = ;   *        *
Reconf.   = *            = ;           *
Inform.    = *            = ;           *
R-forw.         &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;          = *         *
R-repl.         &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           = *         *

section C.1 at page 14 in = draft-ietf-ngtrans-dstm-05.txt describes as followings:
  "This option can be used with the DHCPv6 = Request, Reply, and
   Reconfigure- Init Messages for cases = where a DHCPv6 Server wants to
   assign to clients IPv4-Mapped IPv6 = Addresses, thru the Option Request
   Option (ORO) in DHCPv6."

Question 2 :
In general IPv4 networks, every host has its default = IPv4 gateway address information.
if so, does client need to have a IPv4 default = gateway address information to have IPv4 communications
in DSTM environments?

if so, How does DHCPv6 server inform the client of = IPv4 default gateway address?

if it doesn't have to send IPv4 default gateway = address to client, Why is it?

Question 3 :

In this case that
          &nb= sp;      client reboots,
          &nb= sp;      client is physically disconnected = from a wired connection,
          &nb= sp;      client returns from sleep = mode,
          &nb= sp;      client using a wireless technology = changes access points,
I think client may send confirm message with = multiple options to confirm configuration parameters.
But, why client sends confirm messages with only ORO = option except for IA option?
For example, why doesn=A1=AFt confirm message = include DNS option to confirm DNS Server Address?

It would be appreciated very much if you would kindly = reply to me at your earliest convenience for our questions.

email : hclee@i2soft.net

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C19A9C.B3FAFA70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 11 23:02:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07547; Fri, 11 Jan 2002 23:02:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27218; Fri, 11 Jan 2002 23:01:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27193 for ; Fri, 11 Jan 2002 23:01:34 -0500 (EST) Received: from hotmail.com (oe14.pav1.hotmail.com [64.4.30.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07532 for ; Fri, 11 Jan 2002 23:01:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Jan 2002 20:01:02 -0800 X-Originating-IP: [66.28.18.34] From: "Matt Mullally" To: Date: Fri, 11 Jan 2002 20:52:59 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C19AE1.F4272610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 12 Jan 2002 04:01:02.0670 (UTC) FILETIME=[C05C0EE0:01C19B1D] Subject: [dhcwg] DHCP Automated install Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C19AE1.F4272610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Howdy, I have been recently tasked with having to write a setup program that = will on any (or most) windows platform, simply change the network = setting to use DHCP. I have yet figured out a decent way to do this. = Any ideas? Thanks. Matt ------=_NextPart_000_0018_01C19AE1.F4272610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Howdy,
 
I have been recently tasked with having = to write a=20 setup program that will on any (or most) windows platform, simply change = the=20 network setting to use DHCP.  I have yet figured out a decent way = to do=20 this.  Any ideas?
 
Thanks.
 
Matt
------=_NextPart_000_0018_01C19AE1.F4272610-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 12 01:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09290; Sat, 12 Jan 2002 01:44:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09246; Sat, 12 Jan 2002 01:44:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09221 for ; Sat, 12 Jan 2002 01:44:05 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09281 for ; Sat, 12 Jan 2002 01:43:57 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA00274; Sat, 12 Jan 2002 01:43:46 -0500 Date: Sat, 12 Jan 2002 01:43:46 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'???'" , ngtans???? , DHCP???? Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD67@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id BAA09222 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Bernie is correct. The DSTM draft is in the process of using whats in Draft -22. Currently if the server tells the client via an ORO request a DSTM option the client has to begin that with a solicit via an IA. I believe DSTM implementors will want to justt request an IA with DSTM option at a request. Which can be done too. /jim /jim On Fri, 11 Jan 2002, Bernie Volz (EUD) wrote: > For a Solicit, you would send the DSTM option with an IA Option encapsulated within it. > > The server should then send you back an Advertise with a DSTM Option with an IA Option encapsulated within it (and within the IA Option would be an IA Address Option which contains the V4 address). > > The Request is then sent with what the server sent you (DSTM Option ...). > > In any Renew, Rebind, ... you would continue to send the DSTM Option with IA Option with IA Address Option. > > APPENDIX B is wrong and needs to be fixed. Good catch. DSTM Option is allowed in Solicit, Advert., Request, Confirm, Renew, Rebind, Decline, Release, and Reply. (Same list as that for IA.) > > > A Client CAN NOT place the DSTM option in the ORO option. The reason for this is that a IA ID must be provided and the ORO option can not also provide this. Therefore, the ONLY way a client can request a DSTM address is by sending a DSTM option and encapsulating an IA Option within it (to specify the IA ID). Whereever a IA option can appear, a DSTM option with an encapsulated IA option may appear. > > > Note that the other DSTM I-Ds may not yet be fully in agreement with the changes recently done to the DHCP DSTM option. > > - Bernie > > -----Original Message----- > From: hclee@i2soft.net [mailto:hclee@i2soft.net] > Sent: Friday, January 11, 2002 3:50 AM > To: ngtans????; DHCP???? > Subject: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM > environments > > > We are developing the DSTM client. So we have following up to the DHCPv6 draft 22. > We have several questions about the DHCPv6 draft 22 in a point of view to support > the DSTM environments. > > Question 1 : > According to the draft version 22, when a client request DSTM Global IPv4 address, > the client send IA and IA Address option encapsulated in DSTM Global IP address option. > But, Appendix B describes that DSTM Global IP address option is not included in Request. > Is my thought wrong? > > Do you think that a client should request DSTM Global IPv4 address by transmitting request message > set OPTION_DSTM at within ORO option? > > When a client want to renew, rebind or release for the assigned IPv4 global address, > should I transmit those messsage set OPTION_DSTM at within ORO option to DHCPv6 server? > > I think, if we use DSTM global IPv4 address option at request message, > dhcpv6 spec can support the client which have multiple interfaces. > but, with request message set OPTION_DSTM at within ORO option, it is difficult to support those client. > How do you think about it? > > section 22.11 at draft 22 describes as followings: > "The DSTM Global IPv4 Address Option informs a client or server that > the Identity Association Option (IA) encapsulated in this option > contains or requests an IPv4-Mapped IPv6 Address [10]" > > and also Appendix B at draft 22 describes as followings: > > DUID IA RTA ORO Pref Time Client Server DSTM DSTM > Forw. Forw. Addr Tunn > Solicit * * * * > Advert. * * * * * * * > Request * * * * > Confirm * * * * > Renew * * * * > Rebind * * * * > Decline * * * * > Release * * * * > Reply * * * * * * * > Reconf. * * > Inform. * * > R-forw. * * > R-repl. * * > > section C.1 at page 14 in draft-ietf-ngtrans-dstm-05.txt describes as followings: > "This option can be used with the DHCPv6 Request, Reply, and > Reconfigure- Init Messages for cases where a DHCPv6 Server wants to > assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request > Option (ORO) in DHCPv6." > > Question 2 : > In general IPv4 networks, every host has its default IPv4 gateway address information. > if so, does client need to have a IPv4 default gateway address information to have IPv4 communications > in DSTM environments? > > if so, How does DHCPv6 server inform the client of IPv4 default gateway address? > > if it doesn't have to send IPv4 default gateway address to client, Why is it? > > Question 3 : > > In this case that > client reboots, > client is physically disconnected from a wired connection, > client returns from sleep mode, > client using a wireless technology changes access points, > I think client may send confirm message with multiple options to confirm configuration parameters. > But, why client sends confirm messages with only ORO option except for IA option? > For example, why doesn’t confirm message include DNS option to confirm DNS Server Address? > > It would be appreciated very much if you would kindly reply to me at your earliest convenience for our questions. > > email : hclee@i2soft.net > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 12 12:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22330; Sat, 12 Jan 2002 12:13:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22238; Sat, 12 Jan 2002 12:12:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22211 for ; Sat, 12 Jan 2002 12:12:02 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22323 for ; Sat, 12 Jan 2002 12:11:55 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0CHBxW27362 for ; Sat, 12 Jan 2002 11:11:59 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0CHBxM09083 for ; Sat, 12 Jan 2002 11:11:59 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sat Jan 12 11:11:57 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 12 Jan 2002 11:11:58 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD78@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" Cc: "'???'" , ngtans???? , DHCP???? Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments Date: Sat, 12 Jan 2002 11:11:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19B8C.3D26E350" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19B8C.3D26E350 Content-Type: text/plain; charset="iso-8859-1" Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit): 18.1.1. Creation and transmission of Request messages The client uses a Request message to populate IAs with addresses and obtain other configuration information. The client includes one or more IA options in the Request message, with addresses and information about the IAs that were obtained from the server in a previous Advertise message. The server then returns addresses and other information about the IAs to the client in IA options in a Reply message. I'm not necessarily completely happy with this (as I suspect you aren't), but I think it has some benefits - since it is also possible that if there are multiple servers, some may be configured to provide DSTM addresses and others not? - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Saturday, January 12, 2002 1:44 AM To: Bernie Volz (EUD) Cc: '???'; ngtans????; DHCP???? Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments Bernie is correct. The DSTM draft is in the process of using whats in Draft -22. Currently if the server tells the client via an ORO request a DSTM option the client has to begin that with a solicit via an IA. I believe DSTM implementors will want to justt request an IA with DSTM option at a request. Which can be done too. /jim /jim On Fri, 11 Jan 2002, Bernie Volz (EUD) wrote: > For a Solicit, you would send the DSTM option with an IA Option encapsulated within it. > > The server should then send you back an Advertise with a DSTM Option with an IA Option encapsulated within it (and within the IA Option would be an IA Address Option which contains the V4 address). > > The Request is then sent with what the server sent you (DSTM Option ...). > > In any Renew, Rebind, ... you would continue to send the DSTM Option with IA Option with IA Address Option. > > APPENDIX B is wrong and needs to be fixed. Good catch. DSTM Option is allowed in Solicit, Advert., Request, Confirm, Renew, Rebind, Decline, Release, and Reply. (Same list as that for IA.) > > > A Client CAN NOT place the DSTM option in the ORO option. The reason for this is that a IA ID must be provided and the ORO option can not also provide this. Therefore, the ONLY way a client can request a DSTM address is by sending a DSTM option and encapsulating an IA Option within it (to specify the IA ID). Whereever a IA option can appear, a DSTM option with an encapsulated IA option may appear. > > > Note that the other DSTM I-Ds may not yet be fully in agreement with the changes recently done to the DHCP DSTM option. > > - Bernie > > -----Original Message----- > From: hclee@i2soft.net [mailto:hclee@i2soft.net] > Sent: Friday, January 11, 2002 3:50 AM > To: ngtans????; DHCP???? > Subject: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM > environments > > > We are developing the DSTM client. So we have following up to the DHCPv6 draft 22. > We have several questions about the DHCPv6 draft 22 in a point of view to support > the DSTM environments. > > Question 1 : > According to the draft version 22, when a client request DSTM Global IPv4 address, > the client send IA and IA Address option encapsulated in DSTM Global IP address option. > But, Appendix B describes that DSTM Global IP address option is not included in Request. > Is my thought wrong? > > Do you think that a client should request DSTM Global IPv4 address by transmitting request message > set OPTION_DSTM at within ORO option? > > When a client want to renew, rebind or release for the assigned IPv4 global address, > should I transmit those messsage set OPTION_DSTM at within ORO option to DHCPv6 server? > > I think, if we use DSTM global IPv4 address option at request message, > dhcpv6 spec can support the client which have multiple interfaces. > but, with request message set OPTION_DSTM at within ORO option, it is difficult to support those client. > How do you think about it? > > section 22.11 at draft 22 describes as followings: > "The DSTM Global IPv4 Address Option informs a client or server that > the Identity Association Option (IA) encapsulated in this option > contains or requests an IPv4-Mapped IPv6 Address [10]" > > and also Appendix B at draft 22 describes as followings: > > DUID IA RTA ORO Pref Time Client Server DSTM DSTM > Forw. Forw. Addr Tunn > Solicit * * * * > Advert. * * * * * * * > Request * * * * > Confirm * * * * > Renew * * * * > Rebind * * * * > Decline * * * * > Release * * * * > Reply * * * * * * * > Reconf. * * > Inform. * * > R-forw. * * > R-repl. * * > > section C.1 at page 14 in draft-ietf-ngtrans-dstm-05.txt describes as followings: > "This option can be used with the DHCPv6 Request, Reply, and > Reconfigure- Init Messages for cases where a DHCPv6 Server wants to > assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request > Option (ORO) in DHCPv6." > > Question 2 : > In general IPv4 networks, every host has its default IPv4 gateway address information. > if so, does client need to have a IPv4 default gateway address information to have IPv4 communications > in DSTM environments? > > if so, How does DHCPv6 server inform the client of IPv4 default gateway address? > > if it doesn't have to send IPv4 default gateway address to client, Why is it? > > Question 3 : > > In this case that > client reboots, > client is physically disconnected from a wired connection, > client returns from sleep mode, > client using a wireless technology changes access points, > I think client may send confirm message with multiple options to confirm configuration parameters. > But, why client sends confirm messages with only ORO option except for IA option? > For example, why doesn’t confirm message include DNS option to confirm DNS Server Address? > > It would be appreciated very much if you would kindly reply to me at your earliest convenience for our questions. > > email : hclee@i2soft.net > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C19B8C.3D26E350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM = envir onments

Hum, my understanding of -22 is that a client MUST go = (back) to the Solicit state to "request" new IAs. Request, = Renew, Rebind can only be used on IAs that have been used in a Solicit = (or better yet, returned by a server in an Advertise response to a = Solicit):

18.1.1. Creation and transmission of Request = messages

   The client uses a Request message to = populate IAs with addresses
   and obtain other configuration = information.  The client includes
   one or more IA options in the Request = message, with addresses and
   information about the IAs that were = obtained from the server in a
   previous Advertise message.  The = server then returns addresses and
   other information about the IAs to the = client in IA options in a
   Reply message.

I'm not necessarily completely happy with this (as I = suspect you aren't), but I think it has some benefits - since it is = also possible that if there are multiple servers, some may be = configured to provide DSTM addresses and others not?

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Saturday, January 12, 2002 1:44 AM
To: Bernie Volz (EUD)
Cc: '???'; ngtans????; DHCP????
Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 = to support DSTM
envir onments


Bernie is correct.  The DSTM draft is in the = process of using whats in
Draft -22.

Currently if the server tells the client via an ORO = request a DSTM option
the client has to begin that with a solicit via an = IA.

I believe DSTM implementors will want to justt = request an IA with DSTM
option at a request.  Which can be done = too.

/jim


/jim


On Fri, 11 Jan 2002, Bernie Volz (EUD) wrote:

> For a Solicit, you would send the DSTM option = with an IA Option encapsulated within it.
>
> The server should then send you back an = Advertise with a DSTM Option with an IA Option encapsulated within it = (and within the IA Option would be an IA Address Option which contains = the V4 address).

>
> The Request is then sent with what the server = sent you (DSTM Option ...).
>
> In any Renew, Rebind, ... you would continue to = send the DSTM Option with IA Option with IA Address Option.
>
> APPENDIX B is wrong and needs to be fixed. Good = catch. DSTM Option is allowed in Solicit, Advert., Request, Confirm, = Renew, Rebind, Decline, Release, and Reply. (Same list as that for = IA.)

>
>
> A Client CAN NOT place the DSTM option in the = ORO option. The reason for this is that a IA ID must be provided and = the ORO option can not also provide this. Therefore, the ONLY way a = client can request a DSTM address is by sending a DSTM option and = encapsulating an IA Option within it (to specify the IA ID). Whereever = a IA option can appear, a DSTM option with an encapsulated IA option = may appear.

>
>
> Note that the other DSTM I-Ds may not yet be = fully in agreement with the changes recently done to the DHCP DSTM = option.

>
> - Bernie
>
> -----Original Message-----
> From: hclee@i2soft.net [mailto:hclee@i2soft.net]
> Sent: Friday, January 11, 2002 3:50 AM
> To: ngtans????; DHCP????
> Subject: [dhcwg] Questions about DHCPv6 draft = 22 to support DSTM
> environments
>
>
> We are developing the DSTM client. So we have = following up to the DHCPv6 draft 22.
> We have several questions about the DHCPv6 = draft 22 in a point of view to support
> the DSTM environments.
>
> Question 1 :
> According to the draft version 22, when a = client request DSTM Global IPv4 address,
> the client send IA and IA Address option = encapsulated in DSTM Global IP address option.
> But, Appendix B describes that DSTM Global IP = address option is not included in Request.
> Is my thought wrong?
>
> Do you think that a client should request DSTM = Global IPv4 address by transmitting request message
> set OPTION_DSTM at within ORO option?
>
> When a client want to renew, rebind or release = for the assigned IPv4 global address,
> should I transmit those messsage set = OPTION_DSTM at within ORO option to DHCPv6 server?
>
> I think, if we use DSTM global IPv4 address = option at request message,
> dhcpv6 spec can support the client which have = multiple interfaces.
> but, with request message set OPTION_DSTM at = within ORO option, it is difficult to support those client.
> How do you think about it? 
>
> section 22.11 at draft 22 describes as = followings:
>   "The DSTM Global IPv4 Address = Option informs a client or server that
>    the Identity Association = Option (IA) encapsulated in this option
>    contains or requests an = IPv4-Mapped IPv6 Address [10]"
>
> and also Appendix B at draft 22 describes as = followings:
>
>          = ;   DUID   IA    RTA   = ORO  Pref  Time Client Server DSTM  DSTM
>          = ;            = ;            = ;            = ;            = ;        Forw. Forw.  = Addr    Tunn
> Solicit      = *     *       = *       *
> Advert.     = *     *       = *            = ;    *        = *            = ;            = ;   *         = *
> Request  *     = *        = *       *
> Confirm   *     = *        = *       *
> Renew    = *     *        = *       *
> Rebind    = *     *        = *       *
> Decline   *     = *        = *       *
> Release  *     = *        = *       *
> Reply      = *     *        = *            = ;    *         = *            = ;            = ;   *        *
> Reconf.   = *            = ;           *
> Inform.    = *            = ;           *
> = R-forw.           = ;            = ;            = ;            = ;         = *         *
> = R-repl.           = ;            = ;            = ;            = ;          = *         *
>
> section C.1 at page 14 in = draft-ietf-ngtrans-dstm-05.txt describes as followings:
>   "This option can be used with = the DHCPv6 Request, Reply, and
>    Reconfigure- Init Messages = for cases where a DHCPv6 Server wants to
>    assign to clients IPv4-Mapped = IPv6 Addresses, thru the Option Request
>    Option (ORO) in = DHCPv6."
>
> Question 2 :
> In general IPv4 networks, every host has its = default IPv4 gateway address information.
> if so, does client need to have a IPv4 default = gateway address information to have IPv4 communications
> in DSTM environments?
>
> if so, How does DHCPv6 server inform the client = of IPv4 default gateway address?
>
> if it doesn't have to send IPv4 default gateway = address to client, Why is it?
>
> Question 3 :
>
> In this case that
>          = ;        client reboots,
>          = ;        client is physically = disconnected from a wired connection,
>          = ;        client returns from sleep = mode,
>          = ;        client using a wireless = technology changes access points,
> I think client may send confirm message with = multiple options to confirm configuration parameters.
> But, why client sends confirm messages with = only ORO option except for IA option?
> For example, why doesn=A1=AFt confirm message = include DNS option to confirm DNS Server Address?
>
> It would be appreciated very much if you would = kindly reply to me at your earliest convenience for our = questions.
>
> email : hclee@i2soft.net
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C19B8C.3D26E350-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 12 16:05:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23843; Sat, 12 Jan 2002 16:05:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27060; Sat, 12 Jan 2002 16:04:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27037 for ; Sat, 12 Jan 2002 16:04:29 -0500 (EST) Received: from shaitan.lightconsulting.com ([209.81.42.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23824 for ; Sat, 12 Jan 2002 16:04:26 -0500 (EST) Received: (from thalakan@localhost) by shaitan.lightconsulting.com (8.11.6/8.11.6) id g0CKwiv06913 for dhcwg@ietf.org; Sat, 12 Jan 2002 12:58:44 -0800 (PST) (envelope-from thalakan) Date: Sat, 12 Jan 2002 12:58:44 -0800 From: Jason Spence To: dhcwg@ietf.org Message-ID: <20020112125844.A6885@shaitan.lightconsulting.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD shaitan 4.4-STABLE FreeBSD 4.4-STABLE X-Uptime: 12:51PM up 41 days, 21:30, 5 users, load averages: 6.13, 6.11, 6.08 Subject: [dhcwg] LDAP, NFS home directory attributes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello - I'm not on the list, please CC me on all replies. I was talking with somone today about the number of Freenix systems floating around organizations and how difficult they are to manage due to the extensive manual configuration necessary for them to use directory services and NFS mounted directories. We came to the conclusion that the optimal solution would be to have officially recognized DHCP options for things like the LDAP server with the posixAccounts for the organization and the NFS server serving the home directories. As far as I can tell, no work has been done on creating such attributes, but maybe one of you can prove me wrong. I'm working on a project right now to do this work using non-standard attributes and a patched DHCP client, but would really like to see this standardized in an RFC. My goal is to be able to plug a Freenix box into any one of my client's networks and have it automatically start resolving uid/gids through the LDAP server and mount my home directory, providing a completely consistent environment wherever I go with zero client configuration. -- - Jason Important letters which contain no errors will develop errors in the mail. Corresponding errors will show up in the duplicate while the Boss is reading it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 13 01:21:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29749; Sun, 13 Jan 2002 01:21:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17119; Sun, 13 Jan 2002 01:20:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17085 for ; Sun, 13 Jan 2002 01:20:16 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29743 for ; Sun, 13 Jan 2002 01:20:12 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA14872; Sun, 13 Jan 2002 01:20:00 -0500 Date: Sun, 13 Jan 2002 01:20:00 -0500 (EST) From: Jim Bound Reply-To: Jim Bound To: "Bernie Volz (EUD)" Cc: "'???'" , ngtans???? , DHCP???? Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD78@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Bernie, Our readings are not similar. The server does not have to send addresses back with an advertise but just ack the IA. In 17.2.2 it says: The server MUST include IA options in the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. The server MAY include some or all of the IA options from the client in the Advertise message. If the server will not assign any addresses to IAs in a subsequent Request from the client, the server SHOULD either send an Advertise message to the client that includes only a status code option with the status code set to AddrUnavail and a status message for the user or not respond to the Solicit message. In the first paragraph the IA refers to the Identity Association Option. Not the IA Address Option. The wording is correct in the spec. IA by itself is a reference to the IA option as defined in 22.3. If you then look at 22.4 it references the IA address option specifically. So IA is the association (e.g. IAID, T1 and T2, etc.) To reference the addresses for an IA we say specifically IA Address Option as in 22.4. Hence the server MUST return the IAs but may not return addresses and it can too. The spirit of this was to provide in dhcpv6 the optimization the working group requested so the client could get addresses after solicit from the server. But the server policy can be that the client must do a request to get addresses unless it states specifically ADDRUNAVAIL for a specific IA (association again). On Sat, 12 Jan 2002, Bernie Volz (EUD) wrote: > Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit): > > 18.1.1. Creation and transmission of Request messages > > The client uses a Request message to populate IAs with addresses > and obtain other configuration information. The client includes > one or more IA options in the Request message, with addresses and > information about the IAs that were obtained from the server in a > previous Advertise message. The server then returns addresses and > other information about the IAs to the client in IA options in a > Reply message. So 18.1.1 is correct that the client can later poplulate IAs with addresses by sending IA Address Options with an IA with Request. > > I'm not necessarily completely happy with this (as I suspect you aren't), >but I think it has some benefits - since it is also possible that if >there are multiple servers, some may be configured to provide DSTM >addresses and others not? > We are fine with the current text completely. I believe you may be confusing IAs with IA Address Options. In the case of DSTM the server that tells the client they need a DSTM address in early deployment of IPv6 will also have the DSTM addresses and possibly nothing else for clients. Its purely a server that knows thru user administration that specific clients need DSTM addresses. Its an optimization early on designed in DSTM (go see NGTRANs DSTM discussions and presentations) to permit this kind of relationship via dhcpv6. But as you suggest is also possible and most likely at medium and long term IPv6 deployment where the client is best off going to solicit to find the server. DHCPv6 -22 supports both mechanisms and our IA and IA Address Options work well in both cases and we have done a good job in the working group to support this need from NGTRANS in the community. regards, /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 13 01:27:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29795; Sun, 13 Jan 2002 01:27:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17521; Sun, 13 Jan 2002 01:27:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17452 for ; Sun, 13 Jan 2002 01:27:02 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29788 for ; Sun, 13 Jan 2002 01:26:58 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27715; Sun, 13 Jan 2002 01:26:48 -0500 Date: Sun, 13 Jan 2002 01:26:47 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'???'" , ngtans???? , DHCP???? Subject: Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, So the client could send in a request IA DSTM Option IA Address Option (empty) To the server that sent the Reconfigure. As one way to implement the behavior. The IA is still valid. regards, /jim On Sun, 13 Jan 2002, Jim Bound wrote: > Hi Bernie, > > Our readings are not similar. The server does not have to send addresses > back with an advertise but just ack the IA. > > In 17.2.2 it says: > > The server MUST include IA options in the Advertise message > containing any addresses that would be assigned to IAs contained in > the Solicit message from the client. The server MAY include some or > all of the IA options from the client in the Advertise message. > > If the server will not assign any addresses to IAs in a subsequent > Request from the client, the server SHOULD either send an Advertise > message to the client that includes only a status code option with > the status code set to AddrUnavail and a status message for the user > or not respond to the Solicit message. > > In the first paragraph the IA refers to the Identity Association Option. > Not the IA Address Option. The wording is correct in the spec. IA by > itself is a reference to the IA option as defined in 22.3. If you then > look at 22.4 it references the IA address option specifically. So IA is > the association (e.g. IAID, T1 and T2, etc.) To reference the addresses > for an IA we say specifically IA Address Option as in 22.4. > > Hence the server MUST return the IAs but may not return addresses and it > can too. The spirit of this was to provide in dhcpv6 the optimization the > working group requested so the client could get addresses after solicit > from the server. But the server policy can be that the client must do a > request to get addresses unless it states specifically ADDRUNAVAIL for a > specific IA (association again). > > On Sat, 12 Jan 2002, Bernie Volz (EUD) wrote: > > > Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit): > > > > 18.1.1. Creation and transmission of Request messages > > > > The client uses a Request message to populate IAs with addresses > > and obtain other configuration information. The client includes > > one or more IA options in the Request message, with addresses and > > information about the IAs that were obtained from the server in a > > previous Advertise message. The server then returns addresses and > > other information about the IAs to the client in IA options in a > > Reply message. > > So 18.1.1 is correct that the client can later poplulate IAs with > addresses by sending IA Address Options with an IA with Request. > > > > > I'm not necessarily completely happy with this (as I suspect you aren't), > >but I think it has some benefits - since it is also possible that if > >there are multiple servers, some may be configured to provide DSTM > >addresses and others not? > > > > We are fine with the current text completely. I believe you may be > confusing IAs with IA Address Options. > > In the case of DSTM the server that tells the client they need a DSTM > address in early deployment of IPv6 will also have the DSTM addresses and > possibly nothing else for clients. Its purely a server that knows thru > user administration that specific clients need DSTM addresses. Its an > optimization early on designed in DSTM (go see NGTRANs DSTM discussions > and presentations) to permit this kind of relationship via dhcpv6. > > But as you suggest is also possible and most likely at medium and long > term IPv6 deployment where the client is best off going to solicit to find > the server. > > DHCPv6 -22 supports both mechanisms and our IA and IA Address Options work > well in both cases and we have done a good job in the working group to > support this need from NGTRANS in the community. > > regards, > /jim > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 13 20:44:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16700; Sun, 13 Jan 2002 20:44:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10635; Sun, 13 Jan 2002 20:43:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10616 for ; Sun, 13 Jan 2002 20:43:46 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16695 for ; Sun, 13 Jan 2002 20:43:35 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Mon, 14 Jan 2002 10:45:35 +0900 From: "HeeCheol Lee" To: =?ks_c_5601-1987?B?REhDUL/2xbex17fs?= Date: Mon, 14 Jan 2002 10:42:29 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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.4133.2400 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA10617 Subject: [dhcwg] Many thanks for your reply for our questions about DHCPv6 draft-22 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Dear Jim Bound and Bernie Volz many thanks for your reply and best wishes for the new year to you and your colleagues. I'm HeeCheol Lee at i2soft Corp. in south korea. your reply is very helpful for me. Thanks. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 13 21:25:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16997; Sun, 13 Jan 2002 21:25:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11385; Sun, 13 Jan 2002 21:24:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11359 for ; Sun, 13 Jan 2002 21:24:38 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16993 for ; Sun, 13 Jan 2002 21:24:33 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Mon, 14 Jan 2002 11:26:45 +0900 From: "Kyemyung Jung" To: , , Date: Mon, 14 Jan 2002 11:26:10 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id VAA11360 Subject: [dhcwg] About solicit and advertise messages in Dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit I am developing Dhcpv6 now and have a piece of questions I am wondering about solicit and advertise messages. If a server receives a solicit message, which includes IA with encapsulated IA address option, from client, does dhcpv6 server have to assign IPv6 address? If not, what is the main purpose that solicit message includes IA and IA Address option? I think that server just informs whether it can assign addresses with IA or not, not with IA Address option Isn't it right? Thanks for your reading. I hope that I receive your definite answer as soon as possible. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 06:45:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01376; Mon, 14 Jan 2002 06:45:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03502; Mon, 14 Jan 2002 06:44:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03473 for ; Mon, 14 Jan 2002 06:44:52 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01372 for ; Mon, 14 Jan 2002 06:44:49 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA05672; Mon, 14 Jan 2002 03:44:48 -0800 (PST) Received: from sun.com (vpn-129-159-0-61.EMEA.Sun.COM [129.159.0.61]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id MAA24875; Mon, 14 Jan 2002 12:44:47 +0100 (MET) Message-ID: <3C42C465.3F68702D@sun.com> Date: Mon, 14 Jan 2002 12:43:33 +0100 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jason Spence CC: dhcwg@ietf.org Subject: Re: [dhcwg] LDAP, NFS home directory attributes References: <20020112125844.A6885@shaitan.lightconsulting.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Jason Spence wrote: > I was talking with somone today about the number of Freenix systems > floating around organizations and how difficult they are to manage due > to the extensive manual configuration necessary for them to use > directory services and NFS mounted directories. We came to the > conclusion that the optimal solution would be to have officially > recognized DHCP options for things like the LDAP server with > the posixAccounts for the organization and the NFS server serving the > home directories. As far as I can tell, no work has been done on > creating such attributes, but maybe one of you can prove me wrong. There has been some work on using SLP to adveritse and discover automount table entries. I can get you in contact with those involved if you would like. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 07:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01936; Mon, 14 Jan 2002 07:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05364; Mon, 14 Jan 2002 07:51:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05333 for ; Mon, 14 Jan 2002 07:51:21 -0500 (EST) Received: from pumba.nur.ac.rw (pumba.nur.ac.rw [216.147.148.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01929 for ; Mon, 14 Jan 2002 07:51:12 -0500 (EST) Received: from [216.147.148.12] (account ) by pumba.nur.ac.rw (CommuniGate Pro WebUser 3.4.2) with HTTP id 2345813 for ; Mon, 14 Jan 2002 12:50:34 +0000 From: "Ndabarasa Michel" To: dhcwg@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.2 Date: Mon, 14 Jan 2002 12:50:34 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] a dhcp server under FreeBSD4.2 RELEASE Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit hello, i tried to setup a dhcp server under FreeBSD 4.2 RELEASE but i am stii having problems. can someone provide me with a helpfull HOWTO link/documentation ? best regards /'^ ^'\ ((o)-(o)) |----oOOO--(_)--OOOo--------------|-|- | Ndabarasa Michel............... | | CCNA,CCAI...................... | | National University of Rwanda.. | | Computing Centre............... | | voice.......................... | | office (+250)530666............ | | cell (+250)08425269.......... | |==== .oooO | |.... ( ) Oooo. | |-------\ (--- ( )---------------|-| \_) ) / |-| (_/ ---------------------------------------------- FREE! The Best in Rwanda Email Address @mail.rw Reserve your name right now at http://mail.rw _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 09:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02986; Mon, 14 Jan 2002 09:26:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08226; Mon, 14 Jan 2002 09:23:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08198 for ; Mon, 14 Jan 2002 09:23:12 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02952 for ; Mon, 14 Jan 2002 09:23:10 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0EEMgJ14755 for ; Mon, 14 Jan 2002 08:22:42 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0EEMf909157 for ; Mon, 14 Jan 2002 08:22:41 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Jan 14 08:22:18 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 08:22:18 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD7A@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Kyemyung Jung'" , seamus@bit-net.com, dhcwg@ietf.org Date: Mon, 14 Jan 2002 08:22:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D06.DD801D50" Subject: [dhcwg] RE: About solicit and advertise messages in Dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19D06.DD801D50 Content-Type: text/plain; charset="ks_c_5601-1987" I think this is a server policy issue; the server could chose to give the client one or more of the addresses it requested (if not in use by another client) or it could ignore them. The server may also assign additional addresses. Depending on what the client wants, it can look at the Advertise's received and chose the one that it likes best (for example, the one that gives it the addresses it requested). - Bernie -----Original Message----- From: Kyemyung Jung [mailto:jgm2000@i2soft.net] Sent: Sunday, January 13, 2002 9:26 PM To: seamus@bit-net.com; Bernie.Volz@am1.ericsson.se; dhcwg@ietf.org Subject: About solicit and advertise messages in Dhcpv6 I am developing Dhcpv6 now and have a piece of questions I am wondering about solicit and advertise messages. If a server receives a solicit message, which includes IA with encapsulated IA address option, from client, does dhcpv6 server have to assign IPv6 address? If not, what is the main purpose that solicit message includes IA and IA Address option? I think that server just informs whether it can assign addresses with IA or not, not with IA Address option Isn't it right? Thanks for your reading. I hope that I receive your definite answer as soon as possible. ------_=_NextPart_001_01C19D06.DD801D50 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable RE: About solicit and advertise messages in Dhcpv6

I think this is a server policy issue; the server = could chose to give the client one or more of the addresses it = requested (if not in use by another client) or it could ignore them. = The server may also assign additional addresses.

Depending on what the client wants, it can look at = the Advertise's received and chose the one that it likes best (for = example, the one that gives it the addresses it requested).

- Bernie

-----Original Message-----
From: Kyemyung Jung [mailto:jgm2000@i2soft.net]=
Sent: Sunday, January 13, 2002 9:26 PM
To: seamus@bit-net.com; Bernie.Volz@am1.ericsson.se; = dhcwg@ietf.org
Subject: About solicit and advertise messages in = Dhcpv6


I am developing Dhcpv6 now and have a piece of = questions
I am wondering about solicit and advertise = messages.

If a server receives a solicit message, which = includes IA with encapsulated IA address option, from client,
does dhcpv6 server have to assign IPv6 = address?

If not, what is the main purpose that solicit message = includes IA and IA Address option?

I think that server just informs whether it can = assign addresses with IA or not, not with IA Address option
Isn't it right?

Thanks for your reading.
I hope that I receive your definite answer as soon = as possible.

------_=_NextPart_001_01C19D06.DD801D50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 09:26:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03016; Mon, 14 Jan 2002 09:26:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08144; Mon, 14 Jan 2002 09:19:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08114 for ; Mon, 14 Jan 2002 09:19:26 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02923 for ; Mon, 14 Jan 2002 09:19:24 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0EEIuJ12843 for ; Mon, 14 Jan 2002 08:18:56 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0EEIu907450 for ; Mon, 14 Jan 2002 08:18:56 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Jan 14 08:18:55 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 08:18:55 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD79@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" , "Bernie Volz (EUD)" Cc: "'???'" , ngtans???? , DHCP???? Subject: RE: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to supp ort DSTM envir onments Date: Mon, 14 Jan 2002 08:18:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D06.649649A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19D06.649649A0 Content-Type: text/plain; charset="iso-8859-1" Jim: The client would send a DSTM option with the IA option encapsulated inside the DSTM option. The client need not send the IA Addr option if there are no addresses associated with the IA. The -22 draft has the DSTM option encapsulating the IA option - the DSTM option is the outermost option. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Sunday, January 13, 2002 1:27 AM To: Bernie Volz (EUD) Cc: '???'; ngtans????; DHCP???? Subject: Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments Bernie, So the client could send in a request IA DSTM Option IA Address Option (empty) To the server that sent the Reconfigure. As one way to implement the behavior. The IA is still valid. regards, /jim On Sun, 13 Jan 2002, Jim Bound wrote: > Hi Bernie, > > Our readings are not similar. The server does not have to send addresses > back with an advertise but just ack the IA. > > In 17.2.2 it says: > > The server MUST include IA options in the Advertise message > containing any addresses that would be assigned to IAs contained in > the Solicit message from the client. The server MAY include some or > all of the IA options from the client in the Advertise message. > > If the server will not assign any addresses to IAs in a subsequent > Request from the client, the server SHOULD either send an Advertise > message to the client that includes only a status code option with > the status code set to AddrUnavail and a status message for the user > or not respond to the Solicit message. > > In the first paragraph the IA refers to the Identity Association Option. > Not the IA Address Option. The wording is correct in the spec. IA by > itself is a reference to the IA option as defined in 22.3. If you then > look at 22.4 it references the IA address option specifically. So IA is > the association (e.g. IAID, T1 and T2, etc.) To reference the addresses > for an IA we say specifically IA Address Option as in 22.4. > > Hence the server MUST return the IAs but may not return addresses and it > can too. The spirit of this was to provide in dhcpv6 the optimization the > working group requested so the client could get addresses after solicit > from the server. But the server policy can be that the client must do a > request to get addresses unless it states specifically ADDRUNAVAIL for a > specific IA (association again). > > On Sat, 12 Jan 2002, Bernie Volz (EUD) wrote: > > > Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit): > > > > 18.1.1. Creation and transmission of Request messages > > > > The client uses a Request message to populate IAs with addresses > > and obtain other configuration information. The client includes > > one or more IA options in the Request message, with addresses and > > information about the IAs that were obtained from the server in a > > previous Advertise message. The server then returns addresses and > > other information about the IAs to the client in IA options in a > > Reply message. > > So 18.1.1 is correct that the client can later poplulate IAs with > addresses by sending IA Address Options with an IA with Request. > > > > > I'm not necessarily completely happy with this (as I suspect you aren't), > >but I think it has some benefits - since it is also possible that if > >there are multiple servers, some may be configured to provide DSTM > >addresses and others not? > > > > We are fine with the current text completely. I believe you may be > confusing IAs with IA Address Options. > > In the case of DSTM the server that tells the client they need a DSTM > address in early deployment of IPv6 will also have the DSTM addresses and > possibly nothing else for clients. Its purely a server that knows thru > user administration that specific clients need DSTM addresses. Its an > optimization early on designed in DSTM (go see NGTRANs DSTM discussions > and presentations) to permit this kind of relationship via dhcpv6. > > But as you suggest is also possible and most likely at medium and long > term IPv6 deployment where the client is best off going to solicit to find > the server. > > DHCPv6 -22 supports both mechanisms and our IA and IA Address Options work > well in both cases and we have done a good job in the working group to > support this need from NGTRANS in the community. > > regards, > /jim > > ------_=_NextPart_001_01C19D06.649649A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to = support DSTM envir onments

Jim:

The client would send a DSTM option with the IA = option encapsulated inside the DSTM option. The client need not send = the IA Addr option if there are no addresses associated with the = IA.

The -22 draft has the DSTM option encapsulating the = IA option - the DSTM option is the outermost option.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Sunday, January 13, 2002 1:27 AM
To: Bernie Volz (EUD)
Cc: '???'; ngtans????; DHCP????
Subject: Re: (ngtrans) RE: [dhcwg] Questions about = DHCPv6 draft 22 to
support DSTM envir onments


Bernie,

So the client could send in a request

IA
DSTM Option
IA Address Option (empty)

To the server that sent the Reconfigure.
As one way to implement the behavior.

The IA is still valid.

regards,


/jim


On Sun, 13 Jan 2002, Jim Bound wrote:

> Hi Bernie,
>
> Our readings are not similar.  The server = does not have to send addresses
> back with an advertise but just ack the = IA.
>
> In 17.2.2  it says:
>
>    The server MUST include IA = options in the Advertise message
>    containing any addresses that = would be assigned to IAs contained in
>    the Solicit message from the = client.  The server MAY include some or
>    all of the IA options from = the client in the Advertise message.
>
>    If the server will not assign = any addresses to IAs in a subsequent
>    Request from the client, the = server SHOULD either send an Advertise
>    message to the client that = includes only a status code option with
>    the status code set to = AddrUnavail and a status message for the user
>    or not respond to the Solicit = message.
>
> In the first paragraph the IA refers to the = Identity Association Option.
> Not the IA Address Option.  The wording is = correct in the spec.  IA by
> itself is a reference to the IA option as = defined in 22.3.  If you then
> look at 22.4 it references the IA address = option specifically.  So IA is
> the association (e.g. IAID, T1 and T2, = etc.)   To reference the addresses
> for an IA we say specifically IA Address Option = as in 22.4.
>
> Hence the server MUST return the IAs but may = not return addresses and it
> can too.  The spirit of this was to = provide in dhcpv6 the optimization the
> working group requested so the client could get = addresses after solicit
> from the server.  But the server policy = can be that the client must do a
> request to get addresses unless it states = specifically ADDRUNAVAIL for a
> specific IA (association again).
>
> On Sat, 12 Jan 2002, Bernie Volz (EUD) = wrote:
>
> > Hum, my understanding of -22 is that a = client MUST go (back) to the Solicit state to "request" new = IAs. Request, Renew, Rebind can only be used on IAs that have been used = in a Solicit (or better yet, returned by a server in an Advertise = response to a Solicit):

> >
> > 18.1.1. Creation and transmission of = Request messages
> >
> >    The client uses a = Request message to populate IAs with addresses
> >    and obtain other = configuration information.  The client includes
> >    one or more IA options = in the Request message, with addresses and
> >    information about the = IAs that were obtained from the server in a
> >    previous Advertise = message.  The server then returns addresses and
> >    other information about = the IAs to the client in IA options in a
> >    Reply message.
>
> So 18.1.1 is correct that the client can later = poplulate IAs with
> addresses by sending IA Address Options with an = IA with Request.
>
> >
> > I'm not necessarily completely happy with = this (as I suspect you aren't),
> >but I think it has some benefits - since it = is also possible that if
> >there are multiple servers, some may be = configured to provide DSTM
> >addresses and others not?
> >
>
> We are fine with the current text = completely.  I believe you may be
> confusing IAs with IA Address Options.
>
> In the case of DSTM the server that tells the = client they need a DSTM
> address in early deployment of IPv6 will also = have the DSTM addresses and
> possibly nothing else for clients.  Its = purely a server that knows thru
> user administration that specific clients need = DSTM addresses.  Its an
> optimization early on designed in DSTM (go see = NGTRANs DSTM discussions
> and presentations) to permit this kind of = relationship via dhcpv6.
>
> But as you suggest is also possible and most = likely at medium and long
> term IPv6 deployment where the client is best = off going to solicit to find
> the server.
>
> DHCPv6 -22 supports both mechanisms and our IA = and IA Address Options work
> well in both cases and we have done a good job = in the working group to
> support this need from NGTRANS in the = community.
>
> regards,
> /jim
>
>

------_=_NextPart_001_01C19D06.649649A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 10:19:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03898; Mon, 14 Jan 2002 10:19:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10076; Mon, 14 Jan 2002 10:14:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10058 for ; Mon, 14 Jan 2002 10:14:00 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03833 for ; Mon, 14 Jan 2002 10:13:58 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0EFDuH40228; Mon, 14 Jan 2002 16:13:56 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 630C2C05B; Mon, 14 Jan 2002 16:13:29 +0100 (CET) Date: Mon, 14 Jan 2002 16:13:27 +0100 From: Martin Stiemerling To: Ndabarasa Michel , dhcwg@ietf.org Subject: Re: [dhcwg] a dhcp server under FreeBSD4.2 RELEASE Message-ID: <33310000.1011021207@elgar> In-Reply-To: References: X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit See http://www.isc.org/products/DHCP/ Section Introducy Material and Other Resources. Martin --On Montag, Januar 14, 2002 12:50:34 +0000 Ndabarasa Michel wrote: > can someone provide me with a helpfull HOWTO > link/documentation ? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 17:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21435; Mon, 14 Jan 2002 17:01:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27835; Mon, 14 Jan 2002 17:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27805 for ; Mon, 14 Jan 2002 17:00:59 -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 RAA21410; Mon, 14 Jan 2002 17:00:56 -0500 (EST) Message-Id: <200201142200.RAA21410@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 14 Jan 2002 17:00:56 -0500 Subject: [dhcwg] Last Call: Subnet Selection sub-option for the Relay Agent Information Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG has received a request from the Dynamic Host Configuration Working Group to consider Subnet Selection sub-option for the Relay Agent Information Option 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 January 28, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-subnet-selection-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 17:06:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21619; Mon, 14 Jan 2002 17:06:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28063; Mon, 14 Jan 2002 17:05:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28037 for ; Mon, 14 Jan 2002 17:05:41 -0500 (EST) Received: from gold.chim.unifi.it (gold.chim.unifi.it [150.217.152.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21585 for ; Mon, 14 Jan 2002 17:05:37 -0500 (EST) Date: Mon, 14 Jan 2002 17:05:37 -0500 (EST) Received: from cabd.com ([64.86.192.78]) by gold.chim.unifi.it (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id MAA11902; Mon, 14 Jan 2002 12:53:24 -0800 (PST) Message-ID: <375d529a$1c5$5895> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_11409_8121_1B5D.DFB78020382" To: "dhcwg@ietf.org" From: "" Reply-to: email@ewasher.org Subject: [dhcwg] We guarantee at least 1% response rate Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org ------=_NextPart_11409_8121_1B5D.DFB78020382 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

젨젨젨�

We will put your product or service instantly into the hands of millions!

 

Since 1996, Bulk Email Network has provided bulk email marketing to thousands of

well-satisfied customers. We offer the most competitive prices in the industry, made

possible by our high percentage of repeat business. We have the most advanced direct email technology employed by only a knowledgeable few in the world.

 

We have over 160 million active email addresses All sorted by country, state, city and target.

 

Call us for a free consultation at 323 876 6148� [U.S.A.].

 

We guarantee the lowest prices or your service is free!

 

You will get at least 1% response rate or we will repeat the mailing to a new list for no extra charge.

젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨 젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨젨

�1) Let's say you... Sell a $24.95 PRODUCT or SERVICE.

�2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY.

�3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS.

 

�CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS:

�[Day 1]: $9,980� [Week 1]: $69,860� [Month 1]: $279,440

 

Now you know why you receive so many email advertisements...

 

Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your Business!

 

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

"Many business people are finding out that they can now advertise in ways that they

never could have afforded in the past.� The cost of sending mass e-mail is extremely low, and the response rate is high and quick." - USA TODAY

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

 

 

Best Regards,

 

Jennifer O묬onner,

Bulk Email Network

Marketing Dept.

 

Phone:1(323) 876 6148 [U.S.A.]

 

 

To be Opt-out Please email: optout@ewasher.org with the email address that you would like removed.

 

 

------=_NextPart_11409_8121_1B5D.DFB78020382-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 20:40:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28841; Mon, 14 Jan 2002 20:40:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04829; Mon, 14 Jan 2002 20:37:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04803 for ; Mon, 14 Jan 2002 20:37:23 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28758 for ; Mon, 14 Jan 2002 20:37:19 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Tue, 15 Jan 2002 10:39:22 +0900 From: "Kyemyung Jung" To: , , Date: Tue, 15 Jan 2002 10:39:06 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA04804 Subject: [dhcwg] About OPTION_DSTM_TEP option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Thanks for your answers. I have a question about OPTION_DSTM_TEP option. When a client wants to store TEP address, how does the client send OPTION_DSTM_TEP ? Does the client send OPTION_DSTM_TEP option encapsulated in DSTM Global Address option or thru ORO? Are both of them possible? I hope you to answer my question. Have nice a day !! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 14 20:55:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29068; Mon, 14 Jan 2002 20:55:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05141; Mon, 14 Jan 2002 20:53:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05114 for ; Mon, 14 Jan 2002 20:53:27 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29044 for ; Mon, 14 Jan 2002 20:53:24 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0F1quJ21082 for ; Mon, 14 Jan 2002 19:52:56 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0F1qut23969 for ; Mon, 14 Jan 2002 19:52:56 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 14 19:52:55 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 19:52:55 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD82@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Kyemyung Jung'" , seamus@bit-net.com, dhcwg@ietf.org Date: Mon, 14 Jan 2002 19:52:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D67.583BA220" Subject: [dhcwg] RE: About OPTION_DSTM_TEP option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19D67.583BA220 Content-Type: text/plain; charset="ks_c_5601-1987" A client doesn't send the DSTM_TEP option (except perhaps when echoing back what the server provided earlier to the client in an Advertise or Reply). This option is really for SERVER to CLIENT communication as the server provides the address of the tunnel end point *TO* the client. At least that is my understanding from what is in the DSTM draft. There is no reason for a client to request it. The server will send it if the DSTM option is used and a tunnel end point exists. - Bernie -----Original Message----- From: Kyemyung Jung [mailto:jgm2000@i2soft.net] Sent: Monday, January 14, 2002 8:39 PM To: seamus@bit-net.com; Bernie.Volz@am1.ericsson.se; dhcwg@ietf.org Subject: About OPTION_DSTM_TEP option Thanks for your answers. I have a question about OPTION_DSTM_TEP option. When a client wants to store TEP address, how does the client send OPTION_DSTM_TEP ? Does the client send OPTION_DSTM_TEP option encapsulated in DSTM Global Address option or thru ORO? Are both of them possible? I hope you to answer my question. Have nice a day !! ------_=_NextPart_001_01C19D67.583BA220 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable RE: About OPTION_DSTM_TEP option

A client doesn't send the DSTM_TEP option (except = perhaps when echoing back what the server provided earlier to the = client in an Advertise or Reply). This option is really for SERVER to = CLIENT communication as the server provides the address of the tunnel = end point *TO* the client. At least that is my understanding from what = is in the DSTM draft.

There is no reason for a client to request it. The = server will send it if the DSTM option is used and a tunnel end point = exists.

- Bernie

-----Original Message-----
From: Kyemyung Jung [mailto:jgm2000@i2soft.net]=
Sent: Monday, January 14, 2002 8:39 PM
To: seamus@bit-net.com; Bernie.Volz@am1.ericsson.se; = dhcwg@ietf.org
Subject: About OPTION_DSTM_TEP option


Thanks for your answers.

I have a question about OPTION_DSTM_TEP option. =

When a client wants to store TEP address, how does = the client send OPTION_DSTM_TEP ?

 Does the client send OPTION_DSTM_TEP option = encapsulated in DSTM Global Address option or thru ORO?

 Are both of them possible?

I hope you to answer my question.

Have nice a day !!

------_=_NextPart_001_01C19D67.583BA220-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 15 04:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15637; Tue, 15 Jan 2002 04:01:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26476; Tue, 15 Jan 2002 03:59:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26452 for ; Tue, 15 Jan 2002 03:59:45 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15561 for ; Tue, 15 Jan 2002 03:59:40 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04214; Tue, 15 Jan 2002 03:59:24 -0500 Date: Tue, 15 Jan 2002 03:59:24 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'???'" , ngtans???? , DHCP???? Subject: RE: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to supp ort DSTM envir onments In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD79@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org OK. thats correct. I was presenting the logic model for DSTM processing. thx /jim /jim On Mon, 14 Jan 2002, Bernie Volz (EUD) wrote: > Jim: > > The client would send a DSTM option with the IA option encapsulated inside the DSTM option. The client need not send the IA Addr option if there are no addresses associated with the IA. > > The -22 draft has the DSTM option encapsulating the IA option - the DSTM option is the outermost option. > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Sunday, January 13, 2002 1:27 AM > To: Bernie Volz (EUD) > Cc: '???'; ngtans????; DHCP???? > Subject: Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to > support DSTM envir onments > > > Bernie, > > So the client could send in a request > > IA > DSTM Option > IA Address Option (empty) > > To the server that sent the Reconfigure. > As one way to implement the behavior. > > The IA is still valid. > > regards, > > > /jim > > > On Sun, 13 Jan 2002, Jim Bound wrote: > > > Hi Bernie, > > > > Our readings are not similar. The server does not have to send addresses > > back with an advertise but just ack the IA. > > > > In 17.2.2 it says: > > > > The server MUST include IA options in the Advertise message > > containing any addresses that would be assigned to IAs contained in > > the Solicit message from the client. The server MAY include some or > > all of the IA options from the client in the Advertise message. > > > > If the server will not assign any addresses to IAs in a subsequent > > Request from the client, the server SHOULD either send an Advertise > > message to the client that includes only a status code option with > > the status code set to AddrUnavail and a status message for the user > > or not respond to the Solicit message. > > > > In the first paragraph the IA refers to the Identity Association Option. > > Not the IA Address Option. The wording is correct in the spec. IA by > > itself is a reference to the IA option as defined in 22.3. If you then > > look at 22.4 it references the IA address option specifically. So IA is > > the association (e.g. IAID, T1 and T2, etc.) To reference the addresses > > for an IA we say specifically IA Address Option as in 22.4. > > > > Hence the server MUST return the IAs but may not return addresses and it > > can too. The spirit of this was to provide in dhcpv6 the optimization the > > working group requested so the client could get addresses after solicit > > from the server. But the server policy can be that the client must do a > > request to get addresses unless it states specifically ADDRUNAVAIL for a > > specific IA (association again). > > > > On Sat, 12 Jan 2002, Bernie Volz (EUD) wrote: > > > > > Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit): > > > > > > 18.1.1. Creation and transmission of Request messages > > > > > > The client uses a Request message to populate IAs with addresses > > > and obtain other configuration information. The client includes > > > one or more IA options in the Request message, with addresses and > > > information about the IAs that were obtained from the server in a > > > previous Advertise message. The server then returns addresses and > > > other information about the IAs to the client in IA options in a > > > Reply message. > > > > So 18.1.1 is correct that the client can later poplulate IAs with > > addresses by sending IA Address Options with an IA with Request. > > > > > > > > I'm not necessarily completely happy with this (as I suspect you aren't), > > >but I think it has some benefits - since it is also possible that if > > >there are multiple servers, some may be configured to provide DSTM > > >addresses and others not? > > > > > > > We are fine with the current text completely. I believe you may be > > confusing IAs with IA Address Options. > > > > In the case of DSTM the server that tells the client they need a DSTM > > address in early deployment of IPv6 will also have the DSTM addresses and > > possibly nothing else for clients. Its purely a server that knows thru > > user administration that specific clients need DSTM addresses. Its an > > optimization early on designed in DSTM (go see NGTRANs DSTM discussions > > and presentations) to permit this kind of relationship via dhcpv6. > > > > But as you suggest is also possible and most likely at medium and long > > term IPv6 deployment where the client is best off going to solicit to find > > the server. > > > > DHCPv6 -22 supports both mechanisms and our IA and IA Address Options work > > well in both cases and we have done a good job in the working group to > > support this need from NGTRANS in the community. > > > > regards, > > /jim > > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 15 09:37:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24828; Tue, 15 Jan 2002 09:37:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07904; Tue, 15 Jan 2002 09:36:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07847 for ; Tue, 15 Jan 2002 09:35:36 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24755 for ; Tue, 15 Jan 2002 09:35:32 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id D2696E00328 for ; Tue, 15 Jan 2002 06:34:59 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id UAA25407 for ; Tue, 15 Jan 2002 20:00:45 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Date: Tue, 15 Jan 2002 20:05:56 +0530 Message-ID: <001301c19dd1$f1acbd80$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] static route option for dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I have gone through the dhcpv6 22 spec. I felt that, static route option (option 33 in RFC 2132) is missing. which is useful for routing. Can we include this option also in the spec? thanks and regards Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 15 09:38:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24906; Tue, 15 Jan 2002 09:38:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08026; Tue, 15 Jan 2002 09:37:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10398 for ; Mon, 14 Jan 2002 23:31:34 -0500 (EST) Received: from MARANELLO ([211.192.215.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04151 for ; Mon, 14 Jan 2002 23:31:24 -0500 (EST) Date: Mon, 14 Jan 2002 23:31:24 -0500 (EST) From: steve@memlo.net Message-Id: <200201150431.XAA04151@ietf.org> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="====_ABC123456j7890DEF_====" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 Subject: [dhcwg] RE: Updates to Annex D of 802.1X to align with draft-congdon-radius-8 021x-17.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --====_ABC123456j7890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC09876j54321DEF_====" --====_ABC09876j54321DEF_==== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --====_ABC09876j54321DEF_====-- --====_ABC123456j7890DEF_==== Content-Type: audio/x-wav; name="sample.exe" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO PBG1TzyZqkQ8fbVPPMmzSTxwtU88UmljaHG1TzwAAAAAAAAAANLco1IAAI9/UEUAAEwBBQBAw8I7 AAAAAAAAAADgAA4BCwEGAABwAAAAYAAAAAAAAAd1AAAAEAAAAIAAAAAANzcAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAEAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACEgQAAUAAAAADgAACIHgAAAAAAAAAAAAAAAAAAAAAAAAAAAQBECgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIQBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAKplAAAAEAAAAHAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAq CQAAAIAAAAAQAAAAgAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAiEcAAACQAAAAIAAAAJAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAAAgAAAA4AAAACAAAACwAAAAAAAAAAAAAAAAAABAAABALnJl bG9jAABWCwAAAAABAAAQAAAA0AAAAAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IHsTAcA AFNWVzP/aAwCAACNhbT8//9XUOgYZAAAg8QM/xVcgDc3gKW3/P//f2oBW2aJhbT8//9TiJ22/P// /xWYrDc3V2aJhbj8////FZisNzdXZomFuvz///8VmKw3N1dmiYW+/P///xWYrDc3/3UIZomFvPz/ /42FwPz//1DoAgIAAFk7x1kPjIgAAABqD420BcD8////FZisNzdmiQZGU0b/FZisNzdmiQaNhbT8 //8r8GoQRo1F5EZXUIl1/OhwYwAAahCNRdRXUOhkYwAAi0UMg8QYZsdF5AIAiUXoajX/FZisNzdX agJqAmaJReb/FbysNzeL8IP+/3QYjUXkahBQVv8VuKw3N4XAdCBW/xWcrDc3aAABAAD/dQj/dRD/ FTCBNzeDxAzpRQEAAIl9DGoIjUX0V1Do92IAAIPEDI1F9MdF9B4AAACJtcT+//9QjYXA/v//V1BX V4mdwP7///8VoKw3NzvHD4TcAAAAg/j/D4TTAAAAjYXA/v//UFb/FcCsNzeFwA+EvQAAAFeNhbT8 ////dfxQVv8VqKw3NztF/A+FogAAAGoQjUXEV1Dof2IAAIPEDI1F9Im1xP7//4mdwP7//1BXjYXA /v//V1BX/xWgrDc3O8d0b4P4/3RqjYXA/v//UFb/FcCsNzeFwHRYV42FtPj//2gABAAAUFb/FbCs NzeD+AxyP2aLhbT4//9mO4W0/P//dS+Enbb8//90CfaFt/j//4B0K/aFtvz//wJ1Iv91EI2FtPj/ /1Do0QAAAFmFwFl1L/9FDIN9DAQPjNn+//9oAAEAAP91CP91EP8VMIE3N4PEDFb/FZysNzczwF9e W8nDVv8VnKw3N4vD6/BVi+yB7AQCAABmoRCQNzdWV2gAAgAA/3UMZolF/o2F/P3//zP/UP8VMIE3 N41F/lCNhfz9//9Q/xVwgTc3g8QUiUUMhcB0PYt1CFP/dQzoaGEAAP91DIvYjUYBiB5Q6FJhAACN Rf6NdB4BUGoAjXwfAf8VcIE3N4PEFIlFDIXAdcpb6wOLdQiAJgCNRwFfXsnDVYvsgewcAwAAU1aL dQhXiXX49kYDD3VQZoN+BgCNfgaJffR0Q2aLRgSNXgRQ/xWUrDc3ZokDZosHUP8VlKw3N2aJB2aL RghQ/xWUrDc3ZolGCGaLRgpQ/xWUrDc3ZolGCjPAZjkHdQczwOkAAQAAg8YMZjkDiUUIdlLrAjPA iUXwiUX8oHSkNzdqP4iF8P7//1kzwI298f7///OrZquqjUX8UI1F8FCNhfD+//9QVv91+OhvAQAA A/CDxBQPtwP/RQg5RQh8tYt99DPAM9tmOQeJRQgPhpIAAACNheT8//9QVv91+OiLAQAAg8QMA/D/ te79////FZSsNzeJRfygdKQ3N2o/iIXw/v//WTPAjb3x/v//86tmq6qNhfD+//9QjYXw/f//UP91 +OhFAAAAg8QMhdt0CA+3Rfw72H4cD7dd/I2F8P7//2gAAQAAUP91DP8VMIE3N4PEDItF9P9FCA+3 ADlFCA+Mbv///2oBWF9eW8nDVYvsgewEAgAAoHSkNzdTVldqf4iF/P3//1kzwI29/f3//4tdEPOr ZquF26p1Bo2d/P3//4NlEACDZfwAi3UMigaEwHRbqMB0J2aLBmYlP/9Q/xWUrDc3D7fwA3UIg338 AHXcg0UQAsdF/AEAAADrzw+2+I1GAVdQU+g+XwAAjQQfg8QMg338AMYALo1YAXUKi0UQjUQ4AYlF EI10PgHrn4AjAIN9/ACLRRBfXlt1AUDJw1WL7FNWi3UMV/91EFb/dQjoOf///4tdFIv4g8QMA/eF 23QNZosGUP8VlKw3N2aJA4tdGEdHhdt0DmaLRgJQ/xWUrDc3ZokDjUcCX15bXcNVi+xTVot1EFeF 9nQQaAwCAABqAFboj14AAIPEDIt9DFZX/3UI6NX+//+L2IPEDAP7hfZ0EWaLB1D/FZSsNzdmiYYA AQAAR0dDQ4X2dBFmiwdQ/xWUrDc3ZomGAgEAAEdHQ0OF9nQO/zf/FZCsNzeJhgQBAABmi0cEg8cE UIPDBP8VlKw3N4X2iUUQdAdmiYYIAQAAQ0OF9nQXD7fAg8cCUIHGCgEAAFdW6A1eAACDxAwPt0UQ XwPDXltdw1WL7IHsmAYAAFMz2zkdEK03N4idaP///w+EUgEAAI1F6Ild6FCNRfxQU2g/AA8AU1NT aIyQNzdoAgAAgP8VFIA3N4XAD4W5AQAAVlNTU41F7Is1GIA3N1NQjYVo/f//x0Xs/wAAAFBT/3X8 iV30/9aFwA+F6QAAAI2FaP7//2hMkDc3UOhqXQAAjYVo/f//UI2FaP7//1DoaV0AAIPEEI1F+FBo PwAPAI2FaP7//1NQaAIAAID/FRyANzeFwHVCjUXwx0XwAAQAAFCNhWj5//9QU1NoQJA3N/91+Iid aPn///8VIIA3N42FaPn//1DoBl0AAIXAWXUt/3X4/xUQgDc3/0X0U1NTjUXsU1CNhWj9//9Qx0Xs /wAAAP919P91/OlJ////jYVo+f//aixQ/xVogTc3WTvDWXQCiBiNhWj5//9ogAAAAFCNhWj///9Q /xUwgTc3g8QM/3X4/xUQgDc3/3X8/xUQgDc3XumTAAAAjUX8UGg/AA8AU2gUkDc3aAIAAID/FRyA NzeFwHV1jUXwx0XwAAQAAFCNhWj5//9QU1NoQJA3N/91/IidaPn///8VIIA3N42FaPn//1DoN1wA AIXAWXQzjYVo+f//aixQ/xVogTc3WTvDWXQCiBiNhWj5//9ogAAAAFCNhWj///9Q/xUwgTc3g8QM /3X8/xUQgDc3OJ1o////W3QSjYVo////UP8ViKw3N6NwpDc3agFYycNWi3QkCIX2dBZW6MdbAACF wFl0C4B8MP9cjUQw/3QEM8Bew4AgAGoBWF7DVYvsgewEBAAAU1cz/zk9EK03N3QUagRX/3UI/xVw gDc3agFY6d0AAACNhfz7//9oGLE3N1Doa1sAAI2F/Pv//2gglDc3UOhsWwAAg8QQjYX8+///V2iA AAAAagRXV2gAAABAUP8VbIA3N4vYg/v/D4SPAAAAVmoCV1dT/xVogDc3jYX8+///aBCUNzdQ6BNb AABZjUX8WVdQjYX8+///UOgGWwAAizVkgDc3WVCNhfz7//9QU//WjYX8+///aAiUNzdQ6N1aAAD/ dQiNhfz7//9Q6OBaAACDxBCNRfxXUI2F/Pv//1DowFoAAFlQjYX8+///UFP/1lP/FWCANzdqAVhe 6wIzwF9bycNVi+yB7EABAABWV2iAAAAA/3UI/xV4gDc3M/ZWVmoDVlZoAAAAwP91CP8VbIA3N4v4 g///iX34dQczwOmUAAAAU41F/FZQjUW4akBQV4l1/P8VdIA3N1ZW/3X0V4s9aIA3N//XjUX8VlC7 +AAAAI2FwP7//1NQiXX8/3X4/xV0gDc3OXUMdAtmgaXW/v///9/rB4CN1/7//yBWVv919P91+P/X jUX8VlCNhcD+//9TUP91+Il1/P8VZIA3N/91+P8VYIA3N2om/3UI/xV4gDc3agFYW19eycNVi+yB 7AgCAACNRfxWM/ZQaD8ADwBWaECUNzdoAQAAgMdF+P8BAAD/FRyANzeFwHQDagFejUX4UI2F+P3/ /1BqAGoAaDSUNzf/dfz/FSCANzeFwHQDagFehfZedBONhfj9//9oMJQ3N1DoVVkAAFlZ/3X8/xUQ gDc3jYX4/f//UOgGAAAAWWoBWMnD/xVggTc3a8Bkmbn/fwAA9/lAoxjVNzf/dCQE6BAAAACD+GNZ dPEzyYXAD5XBi8HDVYvsgexIAQAAU1aDZfwAvgAEAABWagj/NRStNzf/FdSsNzeL2IXbD4TcAQAA V1b/dQhT/xUwgTc3U+j5/P///3UI6MdYAACLPVSBNzeLzivIUWiMlDc3U//Xg8QgjYW4/v//UFP/ FYSANzeD+P+JRfh1BzP26X0BAACNheT+//9Q/xVYgTc3jYXk/v//xwQkEJA3N1DohlgAAFmFwFkP hJsAAACNheT+//9oiJQ3N1Doa1gAAFmFwFkPhIAAAAD2hbj+//8QdEJT6EBYAACLzivIUWiElDc3 U//XU+gtWAAAi84ryI2F5P7//1FQU//XU+gK////g8Qk6d8AAABqY1k7wXU6iU386zWNheT+//9Q 6PhXAACD+ARZdiONheT+//9Q/3UI6OIAAABZWWoBWTvBD4SwAAAAx0X8YwAAAI2FuP7//1D/dfj/ FYCANzeFwA+ElAAAAI2F5P7//1D/FViBNzeNheT+///HBCQQkDc3UOipVwAAWYXAWXTCjYXk/v// aIiUNzdQ6JJXAABZhcBZdKv2hbj+//8QD4Rp////Vv91CFP/FTCBNzdT6FxXAACLzivIUWiElDc3 U//XU+hJVwAAi84ryI2F5P7//1FQU//XU+gm/v//g8QwagFZO8EPhRb///+JTfz/dfj/FXyANzeL dfxTagD/NRStNzf/FdCsNzeLxl9eW8nD/w0Y1Tc3eS5WV4s1MIE3N78ABAAAV/90JBRoeKg3N//W V/90JBxoeKQ3N//Wg8QYagFYX17DM8DDVYvsgeywAAAAU1ZXvpyUNzeNvVD///9qHaWlpFkzwI29 Wf///zPb86s5HRCtNzdmq6oPhDsBAADoggQAAIv4O/uL9w+EOQEAAI2FUP///1CNRghQ/xWUgDc3 hcB0Cou2EAEAADvzdeE78w+EEgEAAIs2V+hWBAAAWf8VkIA3NzvGD4T7AAAAVlNo/w8fAP8VjIA3 N4v4O/sPhOQAAABoAIAAAFP/NQytNzdX/xU41jc3oQytNzdqQGgAMAAAi0g8i0wBUFFQV/8VPNY3 NzvDiUX8D4SqAAAAjU3UahxRUFf/FTTWNzeDfegBdGG+ABAAAItF4DvDdFX2RekBdTY7w4ld+HYv i138jUXQUGpAVlNX/xUw1jc3jUX0UFZTU1f/FYiANzcBdfiLReAD3jlF+HLWM9sBRfyNRdRqHFD/ dfxX/xU01jc3g33oAXWkjUXwUFP/NQytNzdoBR83N1NTV/8VQNY3N4XAdBhX/xVggDc36w9qAf8V kIA3N1D/FSzWNzdfXjPAW8nDgeyUAQAAU1VWV+hLKwAAizWsgDc3M/9ouJQ3N1dX/9ZoqJQ3N1dX i9j/1mr//xWogDc3UP8VpIA3Nzk9aNc3N3U0OT0QrTc3dCxXaAAACABX/xXcrDc3O8ejFK03N3UW U/8VYIA3N19eXTPAW4HElAEAAMIEAI1EJBRQaAICAAD/FcisNzf/FaCANzdQ/xUsgTc3Weg2GAAA ix2cgDc3vTB1AABV/9M5PRCtNzd0IuiqTwAAoWjXNzc7x3UEajzrCoP4Y3ULaMgAAADoqA0AAFmL NZiANzdV/9M5PRCtNzd0HoM9aNc3N2N1Beg7EwAAV/81FK03N//W6DMuAADrBeibTAAAV/81FK03 N//W6CwvAABX/zUUrTc3/9ZX6IRNAABX/zUUrTc3/9Y5PRCtNzd0DoM9aNc3N2N0BejqEgAA6Gg0 AABX/zUUrTc3/9boHwAAAMdEJBAYAAAA6H5OAAD/TCQQdfVoIL8CAP/T6WT///9Vi+yB7CgDAABT Vo1F9FdQM9toPwAPAFNoyJU3N2gBAACA/xUcgDc3hcB1T2oEjUX4X4s1CIA3N1dQV1NowJU3N4ld +P919P/WjUX4V1BXU2iwlTc3/3X0/9aNRfhXUFdTaKSVNzf/dfTHRfgBAAAA/9b/dfT/FRCANzc5 HRCtNzcPhDcBAABTU76glTc3aJCVNze/iJU3N1ZXU/8V9Kw3N1NTaHSVNzdWV1P/FfSsNzdTU2hU lTc3VldT/xX0rDc3U1NoLJU3N1ZXU/8V9Kw3N1NTaByVNzdWV1P/FfSsNzewY4hF/+sDikX/vgyV NzeNfdilpaWkiEXeiEXhU41F2FNQaKCVNzdoiJU3N1P/FfSsNzf+Rf+KRf8sYzwYfMiNRfi//gEA AFBoPwAPAFNozJQ3N2gCAACAx0Xw/wAAAIl97P8VHIA3N4XAdXGNReyLNQyANzdQjYXY/P//UFON RfBTUI2F2P7//1BT/3X4iV3o/9aFwHU9jYXY/v//UP91+P8VAIA3N41F7P9F6FCNhdj8//9QU41F 8FNQjYXY/v//UMdF8P8AAAD/deiJfez/dfjrvf91+P8VEIA3N19eW8nD6EMAAACFwHUBw+lHAAAA Vot0JAiF9nQuU4sdSIE3N1eLRgSFwHQNi3gEUP/Thf9Zi8d184u+EAEAAFb/04X/WYv3ddxfW17D 6HQBAADoEgIAAGoBWMNVi+yB7CgBAABTVo1F7Fcz21BTaGTWNzf/NZSUNzfHRewAyAAA6FgHAAD/ NSjWNzeJRfCJXehQ6GkHAAD/NQjWNzeJRfxQ6I0HAAD/dfyJRfSNtdj+///orwcAAIPEJIv4iV34 O/t0XYtF/ItN+DtIKH1SaBQBAAD/FUyBNzc7w1mJhhABAAAPhNIAAAD/dfSL8FfohAcAAIsAV4kG 6JUHAABQjUYIaASWNzdQ/xVQgTc3V4leBOiNBwAAg8Qc/0X4i/jrn4meEAEAAP810NU3N/918OjM BgAA/zWs1Tc3iUX8UOjwBgAA/3X8iUX06BgHAACDxBSDZfgAi9iF23Rji038i0X4O0EofViLQwiL fegzyYXAfg+LvxABAACF/3QwQTvIfPGF/3Qnagj/FUyBNzeL8FmF9nQm/3X0i0cEiUYEiXcEU+jR BgAAiwBZWYkGU+jxBgAA/0X4WYvY650zwOsDi0XoX15bycNVi+yD7BihlJQ3N1OLHRCANzdWV78E AACAO8fHRfwSAAAAdANQ/9OhmJQ3N74CAACAO8Z0A1D/041F/Ik9lJQ3N1CNRehQiTWYlDc3/xW0 gDc3gH3oXHUigH3pXHUciz2wgDc3jUXovnjWNzdQVv/XVmiM1jc3/9frJI1F6L541jc3UGgIljc3 Vv8VUIE3N4PEDFZojNY3N/8VsIA3N19eW8nDVYvsg+wMjUX4UI1F/FCNRfRQ/zWUlDc3/zWYlDc3 6CsGAACDxBSFwHQFg8j/ycNTVldoaJo3N/91+P91/Oi7BwAAaFSaNzejKNY3N/91+P91/OimBwAA aECaNzejJNY3N/91+P91/OiRBwAAuzSaNzejINY3N1P/dfj/dfzoewcAAGgomjc3oxzWNzf/dfj/ dfzoZgcAAGgUmjc3oxjWNzf/dfj/dfzoUQcAAIPESL8Emjc3oxTWNzdX/3X4/3X86DgHAAC+9Jk3 N6MQ1jc3Vv91+P91/OgiBwAAaOiZNzejDNY3N/91+P91/OgNBwAAaNiZNzejCNY3N/91+P91/Oj4 BgAAaMiZNzejBNY3N/91+P91/OjjBgAAaLSZNzejANY3N/91+P91/OjOBgAAg8RIo/zVNzdopJk3 N/91+P91/Oi2BgAAaJyZNzej+NU3N/91+P91/OihBgAAaFSaNzej0NU3N/91+P91/OiMBgAAaECa NzejzNU3N/91+P91/Oh3BgAAU6PI1Tc3/3X4/3X86GYGAABojJk3N6PE1Tc3/3X4/3X86FEGAACD xEijwNU3N2h0mTc3/3X4/3X86DkGAABoYJk3N6O81Tc3/3X4/3X86CQGAABXo7jVNzf/dfj/dfzo EwYAAFajtNU3N/91+P91/OgCBgAAaFSZNzejsNU3N/91+P91/OjtBQAAaESZNzejrNU3N/91+P91 /OjYBQAAg8RIo6jVNzdoPJk3N/91+P91/OjABQAAaDSZNzejpNU3N/91+P91/OirBQAAaCiZNzej oNU3N/91+P91/OiWBQAAaByZNzejnNU3N/91+P91/OiBBQAAaBCZNzejmNU3N/91+P91/OhsBQAA aASZNzejlNU3N/91+P91/OhXBQAAg8RIo5DVNzdo+Jg3N/91+P91/Og/BQAAaOiYNzejjNU3N/91 +P91/OgqBQAAaNiYNzejiNU3N/91+P91/OgVBQAAaMiYNzejhNU3N/91+P91/OgABQAAaLCYNzej gNU3N/91+P91/OjrBAAAaJSYNzejfNU3N/91+P91/OjWBAAAg8RIo3jVNzdoeJg3N/91+P91/Oi+ BAAAaFyYNzejdNU3N/91+P91/OipBAAAaECYNzejcNU3N/91+P91/OiUBAAAaCSYNzejbNU3N/91 +P91/Oh/BAAAaASYNzejaNU3N/91+P91/OhqBAAAaOSXNzejZNU3N/91+P91/OhVBAAAg8RIo2DV NzdoxJc3N/91+P91/Og9BAAAaKyXNzejXNU3N/91+P91/OgoBAAAaJSXNzejWNU3N/91+P91/OgT BAAAaHyXNzejVNU3N/91+P91/Oj+AwAAo1DVNzdoZJc3N/91+P91/OjpAwAAaEyXNzejTNU3N/91 +P91/OjUAwAAg8RIo0jVNzdoMJc3N/91+P91/Oi8AwAAaBCXNzejRNU3N/91+P91/OinAwAAaPCW NzejQNU3N/91+P91/OiSAwAAaNiWNzejPNU3N/91+P91/Oh9AwAAaMCWNzejONU3N/91+P91/Oho AwAAaKiWNzejNNU3N/91+P91/OhTAwAAg8RIozDVNzdokJY3N/91+P91/Og7AwAAaHiWNzejLNU3 N/91+P91/OgmAwAAaFyWNzejKNU3N/91+P91/OgRAwAAaECWNzejJNU3N/91+P91/Oj8AgAAaCSW NzejINU3N/91+P91/OjnAgAA/zXQ1Tc3izVQgTc3oxzVNzf/NSjWNzdoHJY3N2hk1jc3/9aDxEz/ NajVNzf/NaDVNzf/NXzVNzdoEJY3N2hE1jc3/9aDxBT/dfSLNbiANzf/1v91/P/WX14zwFvJw1WL 7P91FI1FEFD/dQz/dQjopAIAAIPEEPfYG8D30CNFEF3DVot0JAhXVjP/6AcDAAA7x1l0Gzl+HHYW i0gMO0wkEHQPUOj/AgAAR1k7fhxy6jPAX17DVot0JAhXVjP/6PUCAAA7x1l0Gzl+IHYWi0gEO0wk EHQPUOjMAgAAR1k7fiBy6jPAX17Di0wkBIXJdAaLQQQDwcMzwMOLRCQIhcB0EItMJASFyXQIi0Ak AwEDwcMzwMOLTCQEhcl0BotBEAPBwzPAw4tEJASFwHQJiwgDyIsBA8HDM8DDVYvsg+wYi00UU1aL dRAzwFeJBokBjU34iz0cgDc3uxkAAgBRU1Bo3Jo3N4lF+P91CIlF9P/XhcCJRRAPhc8AAACNRfzH RfwEAAAAUI1F8P91GFBqAGjMmjc3/3X4/xUggDc3hcCJRRAPhaIAAACNRfxQjUXoUI1F8FBqAGjE mjc3/3X4/xUggDc3hcB0IY1F9MdF7LiaNzdQU2oAaHyaNzf/dQj/14XAiUUQdWPrDYtFDMdF7HCa NzeJRfSNRfyLHSCANzdQjUXwagBQagD/dez/dfT/04XAiUUQdTP/dfyLPSiANzdQ/9eFwIkGdBqL RRiLAI0EhQQAAABQakD/14tNFIXAiQF1SsdFEAgAAACLNos9uIA3N4X2dANW/9eLRRSLAIXAdANQ /9eDffgAizUQgDc3dAX/dfj/1otF9IXAdAg7RQx0A1D/1otFEF9eW8nDjUX8UI1F8P82UGoA/3Xs /3X0/9OFwIlFEHWiizaLPbyANzdW/9eL2IXbdKxW/xU8gTc3WY10HgGLTRg7AXcIi00UiwmJNIFW /9eNdAYBVv/Xi9iF23XV6Xz///9Wi3QkCFcz/4sGhcB0D/90JBRQ/xWUgDc3hcB0D0eDxgQ7fCQQ duEzwF9ew4vH6/lVi+xRU1aLdRBXi30Ugz4AdQz/N2oA/xUogDc3iQa76gAAAIsHiUUQjUUQUI1F /P82UGoA/3UM/3UI/xUggDc3O8OJRRR1Gv82/xW4gDc3gQcABAAA/zdqAP8VKIA3N4kGgz4AdAmL RRQ7w3UN67T/Nv8VuIA3N2oIWF9eW8nDi0wkBIXJdAaLQRgDwcMzwMOLTCQEhcl0BYsBA8HDM8DD i0wkBIXJdAaLQQgDwcMzwMNVi+xWV4t9CDP2O/5+GY1FCIl1CFBWVmirLTc3Vlb/FTCANzdPdedq AVhfXl3D6AkAAABQ6OwAAABZ6/JRav//NbzWNzf/FcyANzf/BcDWNzeBPcDWNzf///9PdgeDJcDW NzcAU1VWV/8VoIA3NwMFwNY3N1D/FSyBNzeLNWCBNzdZ/9bB4AO7/38AAJmLy/f5gz241jc3AIvo dQSF7XUR/9ZpwP8AAACZi8v3+Yv46wSLfCQQg/0DfxCF7XQMiz201jc3gef/AAAA/9ZpwP8AAACZ i8v3+cHgCAv4g/0DfgyLPbTWNzeB5///AAD/1mnA/wAAAJmLy/f5weAQC/j/1mnA/wAAAJn3+/81 vNY3N4vwweYY/xU0gDc3i8YLx19eXVtZw1WL7IHs/AIAAFNWV2oMWb7UnTc3jb0E////g2X8APOl ZqWkizVQgTc3jUW4x0W4FJs3N8dFvCCbNzfHRcAomzc3x0XELJs3N8dFyDCbNzfHRcxEmzc3x0XQ bJs3N8dF1JSbNzfHRdjYmzc3x0Xc7Js3N8dF4ACcNzfHReQUnDc3x0XoKJw3N8dF7ECcNzfHRfBU nDc3x0X0bJw3N4lF+ItF+IsYjYU4////U1Do60QAAIN9/AJZWX0HaICcNzfrBWiQnDc3jYU4//// UOjdRAAAWY2FOP///1lo0J03N1DoykQAAI2FOP///1CNhQT///9QjYWE/f//UP/WjYWE/v//UI2F hP3//1D/dQjoywEAAIPEIIP4Yw+EtwEAAIXAD4SeAQAAjYWE/v//UOgtAwAAhcBZD4SJAQAAM/+N hTj///9TUOhTRAAAg338AllZfQdogJw3N+sFaJCcNzeNhTj///9Q6EVEAABZjYU4////WWjcnDc3 UOggRAAAg338AllZfQdoBJ03N+shhf91B2gUnTc36xaD/wF1B2gknTc36wqD/wJ1E2g0nTc3jYU4 ////UOj2QwAAWVmNhTj///9ooNY3N1CNhQT9//9Q/9aNhTj///9TUOjAQwAAg8QUg338An0HaICc NzfrBWiQnDc3jYU4////UOixQwAAWY2FBP3//1lQjYU4////UOicQwAAjYU4////UI2FBP///1CN hYT9//9Q/9aNhYT+//9QjYWE/f//UP91COidAAAAg8Qgg/hjD4SJAAAAR4N9/AF+CYP/Aw+M4f7/ /4XAdGSNhYT+//9Q6PMBAACFwFl0U42FOP///1NQ6B9DAACNhTj///9owJ03N1DoIEMAAI2FOP// /1CNhQT///9QjYWE/f//UP/WjYWE/v//UI2FhP3//1D/dQjoIQAAAIPEKIP4Y3QR/0X8g0X4BIN9 /BAPjMv9//9qAVhfXlvJw1WL7IHsIAEAAFNWVzP2ahCNReRWUOigQgAAi0UIg8QMZsdF5AIAiUXo alD/FZisNzdWagFbZolF5lNqAv8VvKw3N4v4g///dQczwOktAQAAjUX8iV38UGh+ZgSAV/8VeKw3 N4XAD4UJAQAAjUXkahBQV/8VuKw3N2oIjUX0VlDoNkIAAIPEDI1F9MdF9AUAAACJveT+//9QjYXg /v//VlBWVomd4P7///8VoKw3NzvGD4S7AAAAg/j/D4SyAAAAjYXg/v//UFf/FcCsNzeFwA+EnAAA AI1F/Il1/FBofmYEgFf/FXisNzeFwA+FhAAAAFb/dQzozUEAAFlQ/3UMV/8VqKw3N4P4/3RqagiN RfRWUOikQQAAg8QMjUX0x0X0WgAAAIm95P7//1BWjYXg/v//VlBWiZ3g/v///xWgrDc3O8Z0MIP4 /3QrjYXg/v//UFf/FcCsNzeFwHQZVmp//3UQV/8VsKw3N4P4/3QHi/PrA2pjXlf/FZysNzeLxl9e W8nDi0QkBIpICYD5MnUMgHgKMHUGgHgLMHQRgPk1dRCAeAowdQqAeAsydQRqAVjDM8DDVYvsg+wU U1ZX/xXUgDc3iUX4M9tqAY1LAljT4ItN+IXBdEm+CJ43N419/GalisMEY6SIRfyNRfxQjUXsUOjM QAAAjUXsaISUNzdQ6NBAAACDxBCNRexQ/xXQgDc3g/gDdQqNRfxQ6A8AAABZQ4P7GHyiagFYX15b ycOB7EQBAABTi5wkTAEAAFZXU+hEAgAAg/gEWX8avwAEAABXagj/NRStNzf/FdSsNzeL8IX2dQcz wOkTAgAAV1NW/xUwgTc3Vuh45P//U+hIQAAAix1UgTc3i88ryFFojJQ3N1b/04PEII1EJBBQVv8V hIA3N4P4/4lEJAx1BzP/6bsBAACNRCQ8VVD/FViBNzeNRCRExwQkEJA3N1DoC0AAAIstRIE3N1lZ hcAPhEgBAACNRCRAaIiUNzdQ6Ow/AABZhcBZD4QvAQAA9kQkFBB0Q1f/tCRcAQAAVv8VMIE3N1bo tD8AAIvPK8hRaISUNzdW/9NW6KE/AACLzyvIjUQkYFFQVv/TVuj0/v//g8Qw6eUAAACNRCRAUOh8 PwAAg/gEWQ+G0QAAAI1EJEBoPJ43N1DoYz8AAFmNRARAUOhqPwAAWYXAWXRAjUQkQGg0njc3UOhD PwAAWY1EBEBQ6Eo/AABZhcBZdCCNRCRAaCyeNzdQ6CM/AABZjUQEQFDoKj8AAFmFwFl1cY1EJEBo JJ43N1D/1VmFwFl1TI1EJEBoHJ43N1D/1VmFwFl1Oo1EJEBoFJ43N1D/1VmFwFl1KI1EJEBoDJ43 N1D/1VmFwFl1Fv8VYIE3N2vAZJm5/38AAPf5g/hifhONRCRAUP+0JFwBAADoggAAAFlZjUQkFFD/ dCQU/xWAgDc3hcB0JY1EJEBQ/xVYgTc3jUQkRMcEJBCQNzdQ6IQ+AABZWYXA6Xr+////dCQQ/xV8 gDc3agFfXVZqAP81FK03N/8V0Kw3N4vHX15bgcREAQAAw4tMJAQzwIXJdQHDi9GKCYTJdPeA+Vx1 AUCKSgFC6/BVi+yD7ChWg2X4AL4ABAAAV1ZqCP81FK03N/8V1Kw3N4v4hf+JffwPhIABAABTix0w gTc3Vv91CFf/01foCuL///91COjYPQAAi84ryFFoRJ43N1eLPVSBNzf/14PEIGoA/3X8aBjJNzf/ FdyANzdW/3UI/3X8/9OLXfxT6Mrh////dQjomD0AACvwVmiElDc3U//X/3UI6IU9AAC5/wMAACvI Uf91DFP/14PEMGiAAAAAU/8VeIA3NzP2VlZqA1ZqA2gAAADAU/8VbIA3N4v4g///iX0IdQcz/+m7 AAAAVlf/FSyANzeD+P8PhJ8AAAA9AACAAA+HlAAAAIP4GQ+CiwAAAIsdaIA3N2oCVmrnV//Tg/j/ dHiNRfhWUI1F2GoZUP91CP8VdIA3N4XAdGCAZfEAjUXYUP8VWIE3N79EnTc3V+jZPAAAi8+D6RkD wVCNRdhQ6No8AACDxBCFwHUFagFf6yxqAlZW/3UI/9OD+P90HI1F+FZQV4l1+OigPAAAWVBX/3UI /xVkgDc369Ez//91CP8VYIA3N/91/Fb/NRStNzf/FdCsNzeLx1tfXsnDVYvsg+xAU1ZXjUXAakBQ M/8z2/8VfKw3N41FwFD/FYCsNzeL8ItGDDk4dAyDwARDOTh1+DvfdUPHBbjWNzcBAAAA/zW01jc3 /xWErDc3ahNQaKDWNzf/FTCBNzeDxAxXV1f/FayANzczyTvHD5XBX6O81jc3XovBW8nDiT241jc3 /xVggTc3D6/Dmbn/fwAA9/mLVgwz24sKO890pTvYf6GLCYPCBIkNtNY3N0Pr6IHsTAQAAFNVi6wk WAQAAFZXM/9ViXwkMIl8JCzHRCQU6AIAAIl8JCQz24l8JByJfCQgiXwkGOiGOwAAg/gMWQ+MTwQA AI1EKPRoXJ43N1DofzsAAFmFwFkPhDYEAABXV2oDV2oBaAAAAMBV/xVsgDc3i/CD/v8PhBgEAABX Vv8VLIA3Nz0AAIAAdgxW/xVggDc36f0DAABXV2jWAAAAVv8VaIA3N4P4/3ThjUQkOFdQjUQkRGoB UFb/FXSANzeFwHTJD75EJDw9jwAAAFZ0vf8VYIA3N41EJFxQV2hYnjc3aBi1Nzf/FfyANzeFwA+E oQMAAI1EJFxQ/xUQgTc3jUQkXGhQnjc3UOjAOgAAWY1EJGBZV1BoGME3N/8V3IA3N4XAD4RsAwAA jUQkXGiAAAAAUP8VeIA3N2oCV1X/FQyBNzeL8Dv3iXQkJA+E9AMAAI1EJFxXUP8VCIE3N4voM/87 74lsJDR1DFb/FdiANzfp0AMAAIl8JDAPt0QkMGoDUP90JCz/FQCBNzeL8IX2D4TLAAAAVv90JCj/ FcCANzeFwA+EuAAAAFD/FcSANzeL+IX/D4SnAAAAVv90JCj/FfSANzeFwA+ElAAAALkoAQAAO8F1 EYN8JCAAD4WAAAAAiXwkIOt6PegCAAB1CIXbdW+L3+trPagIAAB1DYN8JBgAdV2JfCQY61c9qA4A AHUNg3wkHAB1SYl8JBzrQz0wAQAAdQ2DfCQUAHU1iXwkFOsvg3wkLAB1CIl8JCyJRCQohdt0HIN8 JCAAdBWDfCQYAHQOg3wkHAB0B4N8JBQAdRf/RCQwgXwkMIAAAAAPjAf///+5KAEAADPSOVQkLHU8 O9oPhYwAAACLRCQgO8J1PjlUJBh1ODlUJBx1ODlUJBR1Zo1EJFxQ/xUQgTc3/3QkJP8V2IA3N+na AQAAO9p1VItEJCiLXCQsiUQkEOtGOVQkHHQOi1wkHMdEJBCoDgAA6zI5VCQYdA6LXCQYx0QkEKgI AADrHjvCdAiL2IlMJBDrEjlUJBR0GYtcJBTHRCQQMAEAADlUJCB0B1H/dCQk6wX/dCQQU4s18IA3 N78ECAAAV2oBagNV/9b/dCQQU1dqAmoDVf/Wg3wkGAB0C2ioCAAA/3QkHOsF/3QkEFNXagNqA1X/ 1oN8JBwAdAtoqA4AAP90JCDrBf90JBBTV2oEagNV/9aDfCQUAHQLaDABAAD/dCQY6wX/dCQQU1dq BWoDVf/W/3QkJP8V2IA3NzPtVVVqA1VqAWgAAACA/7QkeAQAAP8VbIA3N4vYVVP/FSyANzeL6IP9 /3UOU/8VYIA3NzP/6V8BAACNRRBQagj/NRStNzf/FdSsNzeFwIlEJCh1EY1EJFxQ/xUQgTc3U+l8 /P//jUwkOGoAUVVQU/8VdIA3N4XAdRqNRCRcUP8VEIE3N1P/FWCANzf/dCQoagDrSlOLHWCANzf/ 01WLbCQsVVdqZmoK/3QkSP/WhcB1Do1EJFxQ/xUQgTc3VevQM/9X/3QkOP8V7IA3N4XAdSCNRCRc UP8VEIE3N1VX/zUUrTc3/xXQrDc3M8DptgAAAFVX/zUUrTc3/xXQrDc3i7QkYAQAAFdXagNXagFo AAAAgFb/FWyANzeL6IP9/3R6jUQkVFCNRCRIUI1EJFRQVf8V6IA3N1X/01dXagNXV41EJHBoAAAA QFD/FWyANzeL6IP9/3REjUQkVFCNRCRIUI1EJFRQVf8V5IA3N1X/01b/FeCANzeLHXiANzdogAAA AFaL6P/TV41EJGBWUP8V3IA3N1VW/9NqAV+NRCRcUP8VEIE3N4vHX15dW4HETAQAAMNVi+yB7FAB AABTVr4ABAAAV1ZqCP81FK03NzP/iX30iX38iX34/xXUrDc3i9g733UHM8DpGQMAAFb/dQhT/xUw gTc3U+hG2v///3UI6BQ2AACLPVSBNzeLzivIUWiMlDc3U//Xg8QgjYWw/v//UFP/FYSANzeD+P+J RfB1FFNqAP81FK03N/8V0Kw3N+m9AgAAjYXc/v//UP8VWIE3N42F3P7//8cEJBCQNzdQ6MY1AABZ hcBZD4SDAQAAjYXc/v//aIiUNzdQ6Ks1AABZhcBZD4RoAQAA9oWw/v//EHQ2U+iANQAAi84ryFFo hJQ3N1P/11PobTUAAIvOK8iNhdz+//9RUFP/11Po8/7//4PEJOkpAQAAjYXc/v//UOhENQAAg/gE WQ+GEwEAAI2F3P7//2hQnjc3UOgpNQAAWY2EBdj+//9Q6C01AABZhcBZdU9W/3UIU/8VMIE3N1Po BDUAAIvOK8hRaISUNzdT/9dT6PE0AACLzivIjYXc/v//UVBT/9eDxCyDPRCtNzcAD4SrAAAAU+gL +f//WemfAAAAjYXc/v//aIyeNzdQ6LU0AABZjYQF2P7//1DouTQAAFmFwFl1CcdF9AEAAADrcY2F 3P7//2iEnjc3UOiHNAAAWY2EBdj+//9Q6Is0AABZhcBZdCWNhdz+//9ofJ43N1DoYjQAAFmNhAXY /v//UOhmNAAAWYXAWXUJx0X8AQAAAOsejYXc/v//aGyeNzdQ6EY0AABZhcBZdQfHRfgBAAAAjYWw /v//UP918P8VgIA3N4XAD4SLAAAAjYXc/v//UP8VWIE3N42F3P7//8cEJBCQNzdQ6AE0AABZhcBZ dMKNhdz+//9oiJQ3N1Do6jMAAFmFwFl0q/aFsP7//xAPhHX+//9W/3UIU/8VMIE3N1PotDMAAIvO K8hRaISUNzdT/9dT6KEzAACLzivIjYXc/v//UVBT/9dT6Cf9//+DxDDpXf////918P8VfIA3NzP2 U1b/NRStNzf/FdCsNzc5NRCtNzd0KoN99AF1FTl1+P91CHUH6CsCAADrBehCAwAAWTl1/P91CHQj 6HkEAADrIYN99AF1Djl1+HUJ/3UI6AECAABZOXX8dQn/dQjoWAIAAFlqAVhfXlvJw1WL7IHsZAwA AFNWV2icnjc3aBjNNzf/FUSBNzdZhcBZD4X6AAAAM9tqAlNoGME3N/8VDIE3N4v4agpqZlf/FQCB NzdQV4lF/P8VwIA3N1D/FcSANzf/dfyLNfSANzeJRfRX/9aD+GQPgqwAAACNhZz3//9oGME3N1Do izIAAFmNhZz3//9ZiJ2f9///UP8V0IA3N4P4A3VljYWc8///aBi5NzdQ6GAyAACNhZz7//9oGL03 N1DoTzIAAI2FnPP//2ouUP8VaIE3N2iUnjc3UOg1MgAAjYWc+///aISUNzdQ6DYyAACNhZzz//9Q jYWc+///UOgjMgAAg8Qw60qNhZz7//9QU2hYnjc3aBi1Nzf/FfyANzeFwHUOV/8V2IA3NzPA6b4A AACNhZz7//9Q/xUQgTc3jYWc+///aFCeNzdQ6NYxAABZWVNqJmoCU1ONhZz7//9oAAAAQFD/FWyA NzeJRfiNRfBTUP91/Ff/1lD/dfT/dfj/FWSANzf/dfj/FWCANzdX/xXYgDc3akSNRZxeVlNQ6Gox AABqEI1F4FNQ6F4xAACDxBiNReCJdZxmx0XMCgBQjUWcUGgY0Tc3U1NTU1ONhZz7//9oGM03N1D/ FQSBNzeNhZz7//9Q6IPV//9ZagFYX15bycNVi+yB7AAEAAD/dQiNhQD8//9Q6AcxAACNhQD8//9o hJQ3N1DoCDEAAI2FAPz//2hsnjc3UOj3MAAAg8QYjYUA/P//agBQaBjFNzf/FdyANzeNhQD8//9q JlD/FXiANzdqAVjJw1WL7IHsAAQAAFbo6Nb//754qDc3ai5W/xVogTc3WYXAWXQDgCAAaAAEAACN hQD8////dQhQ/xUwgTc3jYUA/P//aISUNzdQ6IAwAACNhQD8//9WUOhzMAAAg8Qc/xVggTc3a8Bk mbn/fwAAXvf5QIP4X34HaHyeNzfrBWiEnjc3jYUA/P//UOhAMAAAWY2FAPz//1lqAFBoGMk3N/8V 3IA3N42FAPz//2iAAAAAUP8VeIA3N2oBWMnDVYvsUVFTVjP2V4s9bIA3N1ZWagNWuwAAAIBqB1No GMU3N//Xg/j/iUX8D4SpAAAAVlD/FSyANzf/dfyD+P+JRfgPhIwAAAD/FWCANzdoAAQAAGoI/zUU rTc3/xXUrDc3/3UIO8aJRfx0clDokS8AAGiElDc3/3X86JYvAABobJ43N/91/OiJLwAAg8QYVlZq A1ZqB1P/dfz/14v4g///dRL/dfxW/zUUrTc3/xXQrDc36yZWV/8VLIA3N4vYg/v/dST/dfxW/zUU rTc3/xXQrDc3V/8VYIA3N/91COgB/v//WTPA61pX/xVggDc3i0X4g8AeO8NyFv8VYIE3N2vAZJm5 /38AAPf5g/hGfiBogAAAAP91/P8VeIA3N/91/P8VEIE3N/91COi2/f//Wf91/Fb/NRStNzf/FdCs NzdqAVhfXlvJw1WL7IHsTAEAAFaDZfwAvgAEAABXVmoI/zUUrTc3/xXUrDc3i/iF/4l99A+EGQIA AFb/dQhX/xUwgTc3V+ir0v///3UI6HkuAAAr8FZojJQ3N1f/FVSBNzeDxCCNhbT+//9QV/8VhIA3 N4P4/4lF+HUUV2oA/zUUrTc3/xXQrDc36cEBAACLNViBNzeNheD+//9Q/9a/EJA3N42F4P7//1dQ 6C4uAACDxAyFwA+EkAAAAI2F4P7//2iIlDc3UOgSLgAAWYXAWXR5jYXg/v//UOjuLQAAg/gEWXZn 9oW0/v//EHVejYXg/v//aISeNzdQ6M4tAABZjYQF3P7//1Do0i0AAFmFwFl0JY2F4P7//2h8njc3 UOipLQAAWY2EBdz+//9Q6K0tAABZhcBZdRSNheD+//9Q/3UI6BEBAABZiUX8WY2FtP7//1OLHYCA NzdQ/3X4/9OFwA+EwAAAAI2F4P7//1D/1o2F4P7//1dQ6GItAACDxAyFwA+EkAAAAI2F4P7//2iI lDc3UOhGLQAAWYXAWXR5jYXg/v//UOgiLQAAg/gEWXZn9oW0/v//EHVejYXg/v//aISeNzdQ6AIt AABZjYQF3P7//1DoBi0AAFmFwFl0JY2F4P7//2h8njc3UOjdLAAAWY2EBdz+//9Q6OEsAABZhcBZ dRSNheD+//9Q/3UI6EUAAABZiUX8WY2FtP7//1D/dfjpNv////91+P8VfIA3N/919GoA/zUUrTc3 /xXQrDc3g338AFt0Cf91COi9+///WWoBWF9eycNTVVZXvwAEAABXagj/NRStNzf/FdSsNzeL8DPb O/MPhO4AAABX/3QkGFb/FTCBNzdW6GnQ//9W6DksAAAr+FeLPVSBNzdohJQ3N1b/11boIiwAALn/ AwAAK8hR/3QkQFb/14PEMP8VYIE3N2vAZJm5/38AAPf5QIP4X34VaIAAAABW/xV4gDc3Vv8VEIE3 N+shU1NqA1OLHWyANze9AAAAgGoHVWgYyTc3/9OL+IP//3UHM//pgQAAAGoAV/8VLIA3N4P4/4lE JBRXdQj/FWCANzfr3os9YIA3N//XM8BQUGoDUGoHVVb/04vYg/v/dMJqAFP/FSyANzeL6IP9/3UW VmoA/zUUrTc3/xXQrDc3U//XM8DrNVP/14tEJBSDwB47xXOOaIAAAABW/xV4gDc3Vv8VEIE3N2oB X1ZqAP81FK03N/8V0Kw3N4vHX15dW8NVi+yB7AAEAABWizUUrTc3V2ggKAAAagBo+Kw3N+j3KgAA g8QMiTUUrTc3agD/FciANzejDK03N+jQAAAAvgAEAAC/GLE3N1ZX/xX4gDc3V+j6zv//Wb8YrTc3 Vlf/FSSBNzdX6ObO//9Zvxi1NzdXVv8VFIE3N1fo0s7//1n/FSCBNzdQaBjNNzfokCoAAFm/GNE3 N1lXVv8VHIE3N1foq87//1mNhQD8//9WUGoA/xUYgTc3jYUA/P//UGgYwTc36FkqAACNhQD8//9q XFD/FUCBNzeL8EZWaBi5NzfoPCoAAIAmAI2FAPz//74YvTc3UFboJyoAAFboUc7//4PEJOg6AAAA agFYX17Jw1WL7IHslAAAAI2FbP///8eFbP///5QAAABQ/xVUgDc3M8CDvXz///8CD5TAoxCtNzfJ w1ZXiz1YgDc3aDChNzf/14XAo/isNzcPhOIAAACLNVCANzdoJKE3N1D/1mgYoTc3o9ysNzf/Nfis Nzf/1mgMoTc3o9isNzf/NfisNzf/1mgAoTc3o9SsNzf/NfisNzf/1mj0oDc3o9CsNzf/NfisNzf/ 1oM9EK03NwCjzKw3N3RcaOCgNzf/NfisNzf/1mjMoDc3o0DWNzf/NfisNzf/1mi8oDc3ozDWNzf/ NfisNzf/1misoDc3ozzWNzf/NfisNzf/1micoDc3ozTWNzf/NfisNzf/1qM41jc36xJohKA3N/81 +Kw3N//WoyzWNzdoeKA3N//XhcCj/Kw3N3UHM8DphwIAAGhooDc3UP/WaGCgNzej9Kw3N//XhcCj AK03N3RVaFCgNzdQ/9ZoPKA3N6PwrDc3/zUArTc3/9ZoLKA3N6PsrDc3/zUArTc3/9ZoFKA3N6Po rDc3/zUArTc3/9ZoAKA3N6PkrDc3/zUArTc3/9aj4Kw3N2j0nzc3/9eFwKMErTc3dHlo6J83N1D/ 1mjYnzc3o1zXNzf/NQStNzf/1mjInzc3o1jXNzf/NQStNzf/1mi4nzc3o1TXNzf/NQStNzf/1mio nzc3o1DXNzf/NQStNzf/1miYnzc3o0zXNzf/NQStNzf/1miMnzc3o0jXNzf/NQStNzf/1qNE1zc3 aICfNzf/14XAowitNzcPhHUBAABodJ83N1D/1mhonzc3o8isNzf/NQitNzf/1mhYnzc3o8SsNzf/ NQitNzf/1mhQnzc3o8CsNzf/NQitNzf/1mhInzc3o7ysNzf/NQitNzf/1mhAnzc3o7isNzf/NQit Nzf/1mg4nzc3o7SsNzf/NQitNzf/1mgsnzc3o7CsNzf/NQitNzf/1mgknzc3o6ysNzf/NQitNzf/ 1mgcnzc3o6isNzf/NQitNzf/1mgUnzc3o6SsNzf/NQitNzf/1mgInzc3o6CsNzf/NQitNzf/1mgA nzc3o5ysNzf/NQitNzf/1mj4njc3o5isNzf/NQitNzf/1mjwnjc3o5SsNzf/NQitNzf/1mjonjc3 o4ysNzf/NQitNzf/1mjcnjc3o5CsNzf/NQitNzf/1mjQnjc3o4isNzf/NQitNzf/1mjEnjc3o4Ss Nzf/NQitNzf/1mi0njc3o3ysNzf/NQitNzf/1qOArDc3aKieNzf/NQitNzf/1qN4rDc3agFYX17D ofisNzdWizXYgDc3hcB0A1D/1qH8rDc3hcB0A1D/1qEArTc3hcB0A1D/1qEErTc3hcB0A1D/1qEI rTc3hcB0A1D/1moBWF7DVYvsgewUBgAAU4sdHIA3N41F9FZQM/ZoPwAPAFZoeKE3N2gCAACA/9OF wA+F2QAAAFdWVlaNRfiLPRiANzdWUI2F7P3//8dF+P8AAABQVv919Il1/P/XhcAPhaEAAACNhez+ //9oQKE3N1DomCUAAI2F7P3//1CNhez+//9Q6JclAACDxBCNRfBQaD8ADwCNhez+//9WUGgCAACA /9OFwHU6jUXsx0XsAAQAAFCNhez5//9QVv918P8VBIA3Nzk1EK03N3QNjYXs+f//UOh76f//Wf91 8P8VEIA3N/9F/FZWVo1F+FZQjYXs/f//UMdF+P8AAAD/dfz/dfTpVf////919P8VEIA3N19eW8nD VYvsgexcBwAAU1Yz9lc5NRCtNzcPhO0AAACNRfDHRfT/AAAAUGg/AA8AVmicojc3aAIAAIDHRfz+ AQAA/xUcgDc3hcAPhekCAACNRfyLPQyANzdQjYWk/P//UFaNRfRWUI2FpP7//1BW/3XwiXX4/9eF wA+FhgAAAIC9pf7//yR0SYtF/DPbM9KNSPw7znY7gLwVpPz//1CNhBWl/P//dRqAOGF1FYB4AXR1 D4B4Amh1CYB4Az11A41YBEI70XLQO950B1Po0e3//1mNRfz/RfhQjYWk/P//UFaNRfRWUI2FpP7/ /1DHRfT/AAAA/3X4x0X8/gEAAP918Olw/////3Xw6SYCAACNReCJdeBQjUXkUFZoPwAPAFZWVmhg ojc3aAIAAID/FRSANzeFwA+FAAIAAFZWVo1F8FaLPRiANzdQjYWk/v//UFb/deTHRfD/AAAAiXX4 /9eLHQiANzeFwA+F7QAAAIC9pf7//yQPhLcAAACNhaD9//9oJKI3N1DodiMAAI2FpP7//1CNhaD9 //9Q6HUjAACDxBCNRfxQaD8ADwCNhaD9//9WUGgCAACA/xUcgDc3hcB1cI1F6MdF6AAEAABQjYWk +P//UFZWaByiNzf/dfzHRfSSAQAA/xUggDc3jUX0agRQagRWaBSiNzf/dfz/01ZWagNWaAiiNzf/ dfz/01ZWagNWaPyhNzf/dfz/042FpPj//1Doe+z//1n/dfz/FRCANzf/RfhWVlaNRfBWUI2FpP7/ /1DHRfD/AAAA/3X4/3Xk/9eFwA+EE////4l19IpF9GoPWb7AoTc3jX2kBEPzpYhF74hF3Y1F4DP2 UI1F/FBWaD8ADwBWVo1FpFZQaAIAAID/FRSANzeFwA+FhQAAAKG8oTc3agSJReiKRe+IRehfjUX4 V1BXVmgUojc3/3X8x0X4kgEAAP/TVlZqA1ZoCKI3N/91/P/TVlZqA1Zo/KE3N/91/P/TjUXoV1Bq AVZoHKI3N/91/P/TVlZqAVZotKE3N/91/P/TjUX4V1BXVmisoTc3/3X8iXX4/9P/dfz/FRCANzf/ RfSDffQYD4Is/////3Xk/xUQgDc3X15bycNVi+yD7BxTVjPbV1OLNWyANzdTagNTagFoAAAAgIld 9P91CP/Wi/iD//8PhJYAAABTV/8VLIA3N4P4/4lF+HUJV/8VYIA3N+t9g8AQUGoI/zUUrTc3/xXU rDc3O8OJRfx03o1N9FNR/3X4UFf/FXSANzeFwFd1CP8VYIA3N+s3/xVggDc3i0X4agMz0ln38TvT iVUIdAdRWCvCiUUIU1NqBFNqAWgAAABA/3UM/9aD+P+JRQx1F/91/FP/NRStNzf/FdCsNzczwOkz AQAAagJTU1D/FWiANzeLRfgz/zPJOV0IagMPlcEz0l739gPBO8OJRfgPhusAAACLdfzrA4tF+Eg7 +IlF8HUVOV0IdBCDfQgBdQQy0usJMtIyyesGilYCik4BitqKBoDjP4hd54rZgOMPwOMCwOoGCtqK 0IDiA4hd5sDiBMDpBArRwOgCiFXliEXk/3Xk6KkAAAD/deWIReTongAAAP915ohF5eiTAAAA/3Xn iEXm6IgAAACDxBA7ffCIRed1FzPbOV0IdBKDfQgBdATGReY9xkXnPesCM9uNRexTUI1F5GoEUP91 DP8VZIA3N0dqE4vHM9JZ9/GF0nUVjUXsU1BqAmjUojc3/3UM/xVkgDc3g8YDO334D4Ia/////3X8 U/81FK03N/8V0Kw3N/91DP8VYIA3N2oBWF9eW8nDikQkBDwZdwMEQcM8GnIHPDN3AwRHwzw0cgc8 PXcDBPzDPD51AwTtwzw/D5XASIPgL8NVi+yD7ChTjUXYVzPbUIld8P8VSIA3Nw+3RdgPt03aacBt AQAAa8keA8FqBA+3Td4DwV+JRfSNRexQjUX8UFNoPwAPAFNTU2jgojc3aAEAAICJffj/FRSANzeF wA+FhQAAAIN97AJWdVKNRfi+2KI3N1CNRehQU1NW/3X8/xUggDc3hcB1IItF6IPACjtF9HNM/3X4 jUX0UFdTVv91/P8VCIA3N+sw/3X4jUX0UFdTVv91/P8VCIA3N+si/3X4jUX0UFdTaNiiNzf/dfz/ FQiANzeFwHUHx0XwAQAAAP91/P8VEIA3N145XfCIHcTWNzdfW3QF6AUAAABqAVjJw1WL7IHsCAQA AI1F/MdF+AAEAABQaD8ADwBqAGhAlDc3aAEAAID/FRyANzeFwHUzjUX4UI2F+Pv//1BqAGoAaNii Nzf/dfz/FSCANzf/dfz/FRCANzeNhfj7//9Q6BAAAABZ6LMJAADo8QMAAGoBWMnDgexEAQAAVle/ AAQAAFdqCP81FK03N/8V1Kw3N4vwhfYPhJoBAABTVYstMIE3N1f/tCRcAQAAVv/VVugNwv///7Qk aAEAAOjXHQAAix1UgTc3i88ryFFojJQ3N1b/04PEII1EJBRQVv8VhIA3N4P4/4lEJBB1BzP/6TAB AACNRCRAUP8VWIE3N41EJETHBCQQkDc3UOibHQAAWYXAWQ+E5gAAAI1EJEBoiJQ3N1Dogh0AAFmF wFkPhM0AAAD2RCQUEHQ8V/+0JFwBAABW/9VW6E4dAACLzyvIUWiElDc3Vv/TVug7HQAAi88ryI1E JGBRUFb/01boBv///+mHAAAAjUQkQFDoGR0AAIP4BFl2eo1EJEBoPJ43N1DoBB0AAFmNRARAUOgL HQAAWYXAWXQgjUQkQGgsnjc3UOjkHAAAWY1EBEBQ6OscAABZhcBZdTpX/7QkXAEAAFb/1VbowhwA AIvPK8hRaISUNzdW/9NW6K8cAACLzyvIjUQkYFFQVv/TVuhDAAAAg8QwjUQkFFD/dCQU/xWAgDc3 hcAPhd3+////dCQQ/xV8gDc3agFfVmoA/zUUrTc3/xXQrDc3XYvHW19egcREAQAAw1WL7IHsCAEA AFNWM9tXU1NqA1NqA2gAAACA/3UIiV34/xVsgDc3i/CD/v90N1NW/xUsgDc3i/iD//+JfQh0HoH/ AACAAHcWV2oI/zUUrTc3/xXUrDc3O8OJRfx1Dlb/FWCANzczwOnkAAAAjU34U1FXUFb/FXSANzeF wFZ1Df8VYIA3NzP26bIAAAD/FWCANzczyTP2M/85XQgPhpoAAACLVfyKBBc8e30lPC1+ITwvdB08 OnwEPD9+FTxbfAQ8Xn4NPGB0CTxAdWZqAV7rYTvzdFk7+XZPi/cr8YP+AnZGgf6AAAAAcz6NRv9Q jUQRAVCNhfj+//9Q6GIbAACNhDX4/v//g8QMiFj/gL34/v//QHQTgHj+QHQNjYX4/v//UOgvAAAA WTP2i8/rBIvPM/ZHO30ID4Jm////agFe/3X8U/81FK03N/8V0Kw3N4vGX15bycNVi+yB7IAAAACD fQgAU1aLNWDXNzdXD4SsAAAAiz0wgTc3u4AAAABTjUWA/3UIUP/XjUWAUP8VWIE3N41FgFDowRoA AIPEFIP4A4lFCHx5jUWAakBQ/xVogTc3WYXAWXRngH2AQHRhi0UIgLwFf////0B0VIX2dBiNRYBW UOiVGgAAWYXAWXRAi7aAAAAA6+RohAAAAGoI/zUUrTc3/xXUrDc3hcB0IYsNYNc3N1OJiIAAAACN TYBRUKNg1zc3/9eDxAxqAVjrAjPAX15bycNTM9s5HWDXNzd1BDPAW8M4HcTWNzdWdUT/FWCBNzdr wGSZuf9/AAD3+YsVYNc3NzvTi8p0+ovwSIX2fAyLiYAAAAA7y3Xv6+dogAAAAFFoxNY3N/8VMIE3 N4PEDDkdYNc3N3Qv/zVg1zc36FIAAAChYNc3N1lQU/81FK03N4uwgAAAAP8V0Kw3NzvziTVg1zc3 ddGhZNc3NzvDdB+LsAABAABQU/81FK03N/8V0Kw3N4vGO/OjZNc3N3XhagFYXlvDVYvsgew8BgAA U1ZX/3UI6GEZAABqQP91CP8VaIE3N4vwM9uDxAw78w+EgQAAAFboQRkAAIP4AllydY2FxPr//0ZQ /zVwpDc3VujjtP//g8QMjYXE+v//UP8VgKw3N4vwO/N0S2oQjUXgU1Do+RgAAA+/RgpQi0YM/zCN ReRQ6PgYAACDxBhmx0XgAgBqGV9X/xWYrDc3U2oBXmaJReJWagL/FbysNzeD+P+JRfx1BzPA6bgD AACJdfSNTfS+fmYEgFFWUP8VeKw3N4XAdAcz9umOAwAAjUXgahBQ/3X8/xW4rDc3jUX0iV30UFb/ dfz/FXisNzeFwHXVvgAEAABqCo2FxPv//1ZQ/3X86FwGAACDxBCFwHS3gL3E+///MnWujYXE+/// aGSjNzdQ6D4YAABZgGXEAFmNRfhQjUXEUIl9+P8VtIA3N41FxGj4AwAAUI2FxPv//1D/FVSBNzeN hcT7//9o1KI3N1DoEhgAAI2FxPv//1ZQjYXE+///UP91/OioBQAAg8QkhcAPhD3///+AvcT7//8y D4Uw////jYXE+///aFSjNzdQ6MAXAAC7xNY3N42FxPv//1NQ6MAXAAC/UKM3N42FxPv//1dQ6K4X AACNhcT7//9WUI2FxPv//1D/dfzoRAUAAIPEKIXAD4TZ/v//gL3E+///Mg+FzP7//42FxPv//2hE ozc3UOhcFwAA/3UIjYXE+///UOhfFwAAjYXE+///V1DoUhcAAI2FxPv//1ZQjYXE+///UP91/Ojo BAAAg8QohcAPhH3+//+AvcT7//8yD4Vw/v//jYXE+///aDyjNzdQ6AAXAACNhcT7//9WUI2FxPv/ /1D/dfzoqAQAAIPEGIXAD4Q9/v//gL3E+///Mw+FMP7//42FxPv//2g0ozc3UOjAFgAAjYXE+/// U1DoxRYAAI2FxPv//1dQ6LgWAACNhcT7//9oKKM3N1DopxYAAI2FxPn//1DojQEAAI2FxPn//1CN hcT7//9Q6IgWAACNhcT7//9o1KI3N1DodxYAAIPENI2FxPv//2o8UOhaFgAAWVCNhcT7//9Q/3X8 6OEEAACDxBCFwA+El/3//zP/V1dqA1dqB2gAAACAaBjJNzf/FWyANzeL2IP7/4ldCA+EcP3//1dT /xUsgDc3g/j/iUX4dQxT/xVggDc36VT9//+DwBBQagj/NRStNzf/FdSsNzeL2DvfdQX/dQjr2I1F 8FdQiX3w/3X4U/91CP8VdIA3N/91CIXAdRn/FWCANzdTV/81FK03N/8V0Kw3N+kC/f///xVggDc3 ajz/dfhT/3X86C0EAACDxBCFwFNX/zUUrTc3dNL/FdCsNzeNhcT7//9oJKM3N1DoaRUAAI2FxPv/ /1ZQjYXE+///UP91/OgRAwAAg8QYhcAPhKb8//+AvcT7//8yD4WZ/P//jYXE+///aByjNzdQ6CkV AACNhcT7//9WUI2FxPv//1D/dfzo0QIAAIPEGGoBXv91/P8VnKw3N4vGX15bycOhZNc3N1aFwHQJ g7gAAQAAAHUu6CG7//++eKg3N2ouVv8VaIE3N1mFwFl0A4AgAGj/AAAAVv90JBD/FVSBNzfrQP8V YIE3N2vAZJm5/38AAPf5iw1k1zc3hcmL0XT6i/BIhfZ8DIuSAAEAAIXSde/r52gAAQAAUv90JBD/ FTCBNzeDxAxqAVhew1WL7IHsCAIAAFeNRfgz/1BXagJXaGyjNzdXiX34/xVc1zc3hcB0BzPA6WgB AACNhfj9//+Apfj9//8AUFeNhfj9//9oAEAAAFBXV/91+P8VVNc3N4XAD4UrAQAAU1aNRfxQaAAI AACNhfj9//9XUFf/dfj/FVDXNzeFwA+F0QAAAItF/DvHD4TGAAAAi0AEO8d0B1DoAAEAAFmLRfyL QBw7x3Q6i3AMO/d0M1boyBMAAIP4Bll2J4A+U3UigH4BTXUcgH4CVHUWgH4DUHUQgH4EOnUKg8YF VuiX+P//WYtN/DPbi0EkO8d0aDtZIHNhA8eFwHRNi3AMhfZ0RlbodxMAAIP4Bll2OoA+U3U1gH4B TXUvgH4CVHUpgH4DUHUjgH4EOnUdg8YFVuhG+P//aIAAAABWaMTWNzf/FTCBNzeDxBCLTfxDg8cY i0EkhcB1mjP//3X8/xVM1zc3jYX4/f//iX38UFeNhfj9//9oAEAAAFBXV/91+P8VVNc3N4XAD4TZ /v//XltXV1f/dfj/FUTXNzdqAVhfycNVi+yB7AABAACDfQgAVos1ZNc3N1d0fIs9MIE3N2j/AAAA /3UIjYUA////UP/Xg8QMgGX/AIX2dBuNhQD///9WUOisEgAAWYXAWXRHi7YAAQAA6+FoBAEAAGoI /zUUrTc3/xXUrDc3hcB0KIsNZNc3N2gAAQAAiYgAAQAAjY0A////UVCjZNc3N//Xg8QMagFY6wIz wF9eycNVi+xqPP91DOg6EgAAWVD/dQz/dQjoxQAAAIPEEIXAdQJdw2o8/3UU/3UQ/3UI6AsAAACD xBD32BvA99hdw1WL7IHsDAEAAFNWV4t9DDPbM/aIH2oIjUX4U1Do3BEAAItFFIPEDIlF+ItFCImF +P7//41F+FBTjYX0/v//U1BTx4X0/v//AQAAAP8VoKw3NzvDdEWD+P90QI2F9P7//1D/dQj/FcCs NzeFwHQsi0UQUyvGSFCNBD5Q/3UI/xWwrDc3g/j/dBI7w3QOA/CAfD7/CnWAagFY6wIzwF9eW8nD VYvsgewMAQAAU1ZXi30IM9sz9moIjUX4U1DoPREAAIPEDI1F+MdF+DwAAACJvfj+//9QjYX0/v// U1BTU8eF9P7//wEAAAD/FaCsNzc7w3RAg/j/dDuNhfT+//9QV/8VwKw3N4XAdCmLRRBTK8ZQi0UM A8ZQV/8VqKw3N4P4/3QQO8N0BwPwO3UQfIdqAVjrAjPAX15bycNRU1VWM/ZXVmgAAAgAVok1FK03 N/8VOIA3NzvGoxStNzcPhL4BAAD/dCQY6JUHAACD+AFZo2jXNzd0Tv90JBjovQYAAIs1rIA3N4s9 PIA3N4XAWb24lDc3u7cAAAB1WzPAOQVo1zc3dVFVUFD/1olEJBD/1zvDdSKDfCQQAHQK/3QkEP8V YIA3N/81FK03N/8VTIA3N+lLAQAA/3QkEP8VYIA3N/90JBjoQwEAAFn/NRStNzf/FUyANzfo7OT/ /4M9aNc3NwB1Bej03P//VWoAagD/1ovw/9c7w3UphfZ0B1b/FWCANzf/FcSsNzfoiOn///81FK03 N/8VTIA3N2oA6doAAABW/xVggDc3M/85PWjXNzd1Ymicnjc3aBjNNzf/FUSBNzdZhcBZdUz/dCQY 6LsAAABZ/xWggDc3UP8VLIE3N1n/FWCBNzdrwGSZuf9/AAD3+YP4UH4F6LIEAAD/FcSsNzfoEOn/ //81FK03N/8VTIA3N+tm6A4CAADoJgMAADk9aNc3N3UF6Hm4//+LNXiANzdqJmiUozc3/9ZqJmiE ozc3/9ZqJmh0ozc3/9Y5PRCtNzd0CYM9aNc3N2N1Blfoyrn///8VxKw3N/81FK03N/8V2Kw3N+ic 6P//V/8VRIA3N2oBWF9eXVtZwgwAVYvsgexUCAAAU1ZX/3UI6P0EAACFwFm/GLU3Nw+FigAAAOih 5P//vgAEAAC7GLE3N1ZT/xX4gDc3U+jLsv//WbsYrTc3VlP/FSSBNzdT6Ley//9ZV1b/FRSBNzdX 6Kiy//9Z/xUggTc3UGgYzTc36GYOAABZuxjRNzdZU1b/FRyBNzdT6IGy///HBCR4oDc3/xVYgDc3 aGigNzdQo/ysNzf/FVCANzej9Kw3N4sdGIE3N42FrPv//2gAAgAAUP91CP/TM/aFwHUPjYWs+/// aAACAABQVv/TjYWs/f//UFZoWJ43N1f/FfyANzeNhaz9//9oUJ43N1Do7w0AAFmNhaz9//9ZVlCN haz7//9Q/xXcgDc3jYWs/f//agFQ6B2z//9qRI1FrF9XVlDopA0AAGoQjUXwVlDomA0AAI2FrP3/ /4l9rFCNhaz3//9QZol13OiEDQAAjYWs9///aKSjNzdQ6IUNAACDxDCNRfBQjUWsUFZWVlZWjYWs 9///VlBW/xUEgTc3jYWs/f//UOijsf//WWoBWF9eW8nDVYvsg+wMU1ZX6D6v//+7GMU3NzP2U1Zo WJ43N2gYtTc3/xX8gDc3U/8VEIE3N2hQnjc3U+gYDQAAWVlWU2gYwTc3/xXcgDc3aIAAAABT/xV4 gDc3VlP/FQiBNze+tKM3N4199KWkagGNTfRfiUX8V1FoBAgAAGpmagpQ/xXwgDc3M/ZW/3X8/xXs gDc3VlPoELL//1PoALH//4PEDFZWagNWagNoAAAAwFP/FWyANzeL2IP7/3RfVlZo0AAAAFP/FWiA NzeD+P90RTk1cKQ3N3UYjUX8VlBqBGhwpDc3U4l1/P8VdIA3N+sWjUX8VlBqBGhwpDc3U4l1/P8V ZIA3N4XAdQtT/xVggDc3M8DrCVP/FWCANzeLx19eW8nDgewQBAAAU1VWjUQkHFcz21BTaFieNzdo GLU3N/8V/IA3N41EJCBTUGgYwTc3/xXcgDc3vYAAAACNRCQgVVD/FXiANzeNRCQgU1D/FQiBNze+ tKM3N418JBiNTCQYagGlUWgECAAAamZqClCJRCQopP8V8IA3N1P/dCQU/xXsgDc3vhjJNzdWU2hY njc3aBi1Nzf/FfyANzeLPWyANzdTVWoCU1NoAAAAQFb/14P4/4lEJBB1ElaLNRCBNzf/1o1EJCBQ /9brX41EJBRTUGgMkTc36FELAABZUGgMkTc3/3QkIP8VZIA3N/90JBD/FWCANzeNRCQgVlDoY+n/ /1mNRCQkWVD/FRCBNzdTVWoEU1NoAAAAQFb/14v4g///dQtW/xUQgTc3M8DrNGoCU1NX/xVogDc3 jUQkFFO+4JM3N1BWiVwkIOjeCgAAWVBWV/8VZIA3N1f/FWCANzdqAVhfXl1bgcQQBAAAw4HsRAEA AFNVVle/AAQAAFdqCP81FK03N/8V1Kw3N4vwhfYPhL0AAAC9GLU3N1dVVv8VMIE3N1bora7//1Xo fQoAAIsdVIE3N4vPK8hRaLyjNzdW/9ODxCCNRCQUUFb/FYSANzeD+P+JRCQQdRFWagD/NRStNzf/ FdCsNzfrZFdVVv8VMIE3N1boMgoAAIvPK8hRaISUNzdW/9NW6B8KAACLzyvIjUQkYFFQVv/Tg8Qs Vv8VEIE3N41EJBRQ/3QkFP8VgIA3N4XAdbRWUP81FK03N/8V0Kw3N/90JBD/FXyANzdqAVhfXl1b gcREAQAAw1WL7IHsIAQAAFNWizUYgTc3V4Cl4Pv//wC/AAQAAI2F4Pv//1dQ/3UI/9aFwHUMjYXg +///V1BqAP/WjYXg+///UOiICQAAi9hZg/sFfG2NtB3g+///jUb8UI1F4FDoZgkAAIs9WIE3N41F 4FD/141F4GhQnjc3UOhkCQAAg8QUhcB0OIP7Cn0EM8DrMoPG941F4FZQ6C8JAACNReBQ/9eNReBo zKM3N1DoMwkAAIPEFPfYG8AknYPAY+sDagFYX15bycNVi+yB7FQIAABWV/91COgp////g/hjWQ+F CQEAADP2aLiUNzdWVv8VrIA3N4v4/xU8gDc3PbcAAAB1Ezv+dAdX/xVggDc3agFY6RoBAABTV/8V YIA3N4sdGIE3N78ABAAAjYWs9///V1D/dQj/04XAdQuNhaz3//9XUFb/042FrPv//1dQ/xX4gDc3 jYWs+///UOierP//jYWs+///xwQk+KM3N1DobQgAAFmNhaz7//9ZVlCNhaz3//9Q/xXcgDc3jYWs +///agFQ6Jut//+Nhaz7//9o6KM3N1DoNwgAAGpEjUWsX1dWUOgRCAAAahCNRfBWUOgFCAAAg8Qo jUXwiX2sZol13FCNRaxQVlZWVlaNhaz7//9WUFb/FQSBNzdqAVhb60JoAAQAAP8VIIE3N1CNhaz3 //9Q/xUwgTc3jYWs9///UP8VWIE3N42FrPf//2jcozc3UP8VRIE3N4PEGPfYG8CD4GNfXsnDVYvs gewABAAAU1aLNTCBNze79gMAAFdTjYUA/P//aBitNzdQ/9aNhQD8//9oVKQ3N1DodAcAAIPEFI2F APz//2oAUGgYwTc3/xXcgDc3iz14gDc3jYUA/P//aiZQ/9dTjYUA/P//aBixNzdQ/9aNhQD8//9o SKQ3N1DoLAcAAIPEFI2FAPz//1BoJKQ3N2gcpDc3aBSkNzf/FUCANzdTjYUA/P//aBitNzdQ/9aN hQD8//9oBKQ3N1Do7QYAAIPEFI2FAPz//2iAAAAAUP/XjYUA/P//agBQaBjBNzf/FdyANzeNhQD8 //9qAFDoDaz//1mNhQD8//9ZaiZQ/9dqAVhfXlvJw1WL7IPsNI1F9FeDTfz/UP91CDP/x0X4AEAA AFdXagL/FeisNzeFwHQHM8DpBAEAAFNW/3X4agj/NRStNzf/FdSsNzeL8I1F+FCNRfxWUP919Il1 7P8V7Kw3NzvHiUXoD4WOAAAAOX38iX0ID4aJAAAAg8YUg37wAXVTjUXwx0XwGQAAAFCNRcxQ/xW0 gDc3V41e7FdXU/8V4Kw3N4XAdRT/NuiNz///WVdX/zb/FeSsNzfrGVeNRcxXUFP/FeCsNzf/NoXA dNvoaM///1mLRviD4AI8AnUJjUbsUOgg/////0UIg8Ygi0UIO0X8coaLdezrBz0DAQAAdRxWV/81 FK03N/8V0Kw3N4F96AMBAAB0E+kc////Vlf/NRStNzf/FdCsNzf/dfT/FfCsNzf32BvAXkBbX8nC BABVi+yB7LAAAABW6Ma+//9Q/xWErDc3aj9QjYVQ////UP8VMIE3N41FkGhgpDc3UOgmBQAAjYVQ ////ajxQjUWQUP8VVIE3N2ogjUXgagBQ6AAFAACDxCyDZegAjUWQx0XgAgAAAGoBiUX0Xo1F4FCJ deSJdezoTf7//4vGXsnDUY1EJABQM8BQUGh/bzc3UFD/FTCANzdqAVhZw1WL7IHsRAYAAFNWavH/ FaiANzdQ/xWkgDc3M9tTU1P/FayANzc7w6Ns1zc3dQgzwF5bycIEAGoQjUXcU1DodwQAAIPEDGbH RdwCAFP/FYysNzdqRYlF4P8VmKw3N1NqAmoCZolF3v8VvKw3N4vwg/7/iXX8dLhXjUXcahBQVv8V tKw3N4XAdAxW/xWcrDc3M8Bf65xqEFiJRfhQjUXMU1DoFAQAAIPEDI1F+FCNRcxQU42FxP3//2gE AgAAUP91/P8VrKw3N4P4/3TJjYXE/f//agRQjYW8+f//UOjrAwAAg8QMagH/FZSsNzdmOYW8+f// daCNhcb9//9oAgIAAFCNhcD7//9Q6L8DAACNhcD7//9Q6K0DAACDxBA7ww+Ecf///z36AQAAD41m ////jYQFx/3//2oGUI1F7FDoigMAAI1F7Ihd8VD/FViBNzeNRexoZKQ3N1DoewMAAIPEGIXAD4Ut ////av//NWzXNzf/FcyANzehcNc3NzvDdBeLSAQ7TdB1CmaLSAJmO03OdEOLQBDr5WoUagj/NRSt Nzf/FdSsNzc7w3QqjXXMi/ilpaWliw1w1zc3iUgQjU3IUVNQaGNxNzdTU6Nw1zc3/xUwgDc3/zVs 1zc3/xU0gDc36bD+//9Vi+yB7CwFAABTVldq8f8VqIA3N1D/FaSANzcz9lZqAmoC/xW8rDc3i/iD //8PhDwCAABqEP91CFf/FbisNzeFwA+FIQIAAFZWagNWagdoAAAAgGgYxTc3/xVsgDc3g/j/iUXg D4T+AQAAVlD/FSyANzeD+P8PhOQBAABqAYlF+FuJXfRqA/8VmKw3N/919GaJhdj8////FZisNzc5 dfhmiYXa/P//iXX8dCKNRfxWUI2F3Pz//2gAAgAAUP914P8VdIA3N4tF/ClF+OsEg034/4l18IN9 8AYPjYEBAABqCI1F5FZQiXXs6OgBAACDxAyNReTHReQCAAAAib3g/v//UI2F3P7//1ZQVlaJndz+ ////FaCsNzc7xg+EQAEAAIP4/w+ENwEAAI2F3P7//1BX/xXArDc3hcAPhCEBAACLRfxWg8AEUI2F 2Pz//1BX/xWorDc3jUXkUI2F3P7//1ZQVlb/FaCsNzc7xg+E7wAAAIP4/w+E5gAAAI2F3P7//1BX /xXArDc3hcAPhNAAAACLRfxWg8AEUI2F2Pz//1BX/xWorDc3/0XsagiNReRWUOghAQAAg8QMjUXk x0XkAgAAAIm94P7//1BWjYXc/v//VlBWiZ3c/v///xWgrDc3O8Z0Y4P4/3RejYXc/v//UFf/FcCs NzeFwHRMVo2F1Pr//2gEAgAAUFf/FbCsNzf/tdT6////FZSsNzdmPQUAdED/tdT6////FZSsNzdm PQQAdRT/tdb6////FZSsNzcPt8A7RfR0EoN97AMPjFb/////RfDpff7///9F9Okl/v///3Xg/xVg gDc3V/8VnKw3N2r//zVs1zc3/xXMgDc3oXDXNze5cNc3NzvGdDSLfQiLVwQ5UAR1CmaLWAJmO18C dAyNSBCLQBA7xnXn6xOLUBBQVokR/zUUrTc3/xXQrDc3/zVs1zc3/xU0gDc3X14zwFvJwgQAzP8l fIE3N/8leIE3N/8ldIE3N/8lbIE3N/8lZIE3N/8lXIE3N4tEJAiFwHUOOQV01zc3fi7/DXTXNzeL DTiBNzeD+AGLCYkNeNc3N3U/aIAAAAD/FUyBNzeFwFmjgNc3N3UEM8DrZoMgAKGA1zc3aASQNzdo AJA3N6N81zc36OoAAAD/BXTXNzdZWes9hcB1OaGA1zc3hcB0MIsNfNc3N1aNcfw78HISiw6FyXQH /9GhgNc3N4PuBOvqUP8VSIE3N4MlgNc3NwBZXmoBWMIMAFWL7FOLXQhWi3UMV4t9EIX2dQmDPXTX NzcA6yaD/gF0BYP+AnUioYTXNzeFwHQJV1ZT/9CFwHQMV1ZT6BX///+FwHUEM8DrTldWU+gd7v// g/4BiUUMdQyFwHU3V1BT6PH+//+F9nQFg/4DdSZXVlPo4P7//4XAdQMhRQyDfQwAdBGhhNc3N4XA dAhXVlP/0IlFDItFDF9eW13CDAD/JTSBNzcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYiAAACokA APiIAADoiAAAhIgAAMaIAAC2iAAApogAAJKIAAAAAAAAwIUAACiGAADOhQAA3oUAAEqIAAA6iAAA WIgAAB6IAAAOiAAALIgAAOyHAADchwAA/ocAADaEAABMhAAAWoQAAGaEAAB4hAAAhoQAAJSEAACg hAAAtoQAAMKEAADShAAA5IQAAPqEAAAIhQAAHoUAACqFAAA4hQAAQIUAAFCFAABkhQAAeIUAAIiF AACUhQAAqIUAALSFAAC+hgAAroYAAMiHAADuhQAABIYAABSGAADehgAANoYAAEKGAABYhgAAZoYA AHSGAACKhgAAnIYAALCHAAAkhwAAzoYAADiHAADshgAABIcAABaHAACKhwAASocAAGCHAAB4hwAA mocAAAAAAADOgwAAWIMAABqEAAAmhAAA8oMAAASEAAD6gwAA1oMAAOiDAADegwAAxIMAALqDAACw gwAAqIMAAJ6DAACUgwAAioMAAICDAAB2gwAAbIMAAGKDAAAAAAAAAIMAAAAAAAAAAAAADoQAACyB AAD8gQAAAAAAAAAAAAB2iAAAKIAAANSBAAAAAAAAAAAAAByJAAAAgAAAAAAAAAAAAAAAAAAAAAAA AAAAAADYiAAACokAAPiIAADoiAAAhIgAAMaIAAC2iAAApogAAJKIAAAAAAAAwIUAACiGAADOhQAA 3oUAAEqIAAA6iAAAWIgAAB6IAAAOiAAALIgAAOyHAADchwAA/ocAADaEAABMhAAAWoQAAGaEAAB4 hAAAhoQAAJSEAACghAAAtoQAAMKEAADShAAA5IQAAPqEAAAIhQAAHoUAACqFAAA4hQAAQIUAAFCF AABkhQAAeIUAAIiFAACUhQAAqIUAALSFAAC+hgAAroYAAMiHAADuhQAABIYAABSGAADehgAANoYA AEKGAABYhgAAZoYAAHSGAACKhgAAnIYAALCHAAAkhwAAzoYAADiHAADshgAABIcAABaHAACKhwAA SocAAGCHAAB4hwAAmocAAAAAAADOgwAAWIMAABqEAAAmhAAA8oMAAASEAAD6gwAA1oMAAOiDAADe gwAAxIMAALqDAACwgwAAqIMAAJ6DAACUgwAAioMAAICDAAB2gwAAbIMAAGKDAAAAAAAAwQJzdHJu Y3B5AJkCbWVtc2V0AAC6AnN0cmNweQAAvgJzdHJsZW4AAMcCc3RydG9rAACXAm1lbWNweQAAtwJz dHJjaHIAALYCc3RyY2F0AACmAnJhbmQAALgCc3RyY21wAADDAV9zdHJsd3IAvwJzdHJuY2F0ALQC c3JhbmQAXgJmcmVlAACyAnNwcmludGYAkQJtYWxsb2MAAD0CYXRvaQAAxQJzdHJzdHIAAMMCc3Ry cmNocgBNU1ZDUlQuZGxsAAAPAV9pbml0dGVybQCdAF9hZGp1c3RfZmRpdgAA+gBHZXRDdXJyZW50 VGhyZWFkSWQAABsAQ2xvc2VIYW5kbGUA3wJXcml0ZUZpbGUAagJTZXRGaWxlUG9pbnRlcgAANABD cmVhdGVGaWxlQQDeAU1vdmVGaWxlRXhBABgCUmVhZEZpbGUAAGgCU2V0RmlsZUF0dHJpYnV0ZXNB AACQAEZpbmRDbG9zZQCdAEZpbmROZXh0RmlsZUEAlABGaW5kRmlyc3RGaWxlQQAA6QJXcml0ZVBy b2Nlc3NNZW1vcnkAAO8BT3BlblByb2Nlc3MA+ABHZXRDdXJyZW50UHJvY2Vzc0lkAP8CbHN0cmNt cGlBAJoBSGVhcENvbXBhY3QAlgJTbGVlcABtAUdldFRpY2tDb3VudAAAhwJTZXRUaHJlYWRQcmlv cml0eQD5AEdldEN1cnJlbnRUaHJlYWQAAD8AQ3JlYXRlTXV0ZXhBAAACA2xzdHJjcHlBAADOAEdl dENvbXB1dGVyTmFtZUEAAMwBTG9jYWxGcmVlAAgDbHN0cmxlbkEAAMgBTG9jYWxBbGxvYwAASgBD cmVhdGVUaHJlYWQAACUCUmVsZWFzZU11dGV4AADOAldhaXRGb3JTaW5nbGVPYmplY3QABAFHZXRE cml2ZVR5cGVBACABR2V0TG9naWNhbERyaXZlcwAAEgFHZXRGaWxlU2l6ZQAoAENvcHlGaWxlQQAN AUdldEZpbGVBdHRyaWJ1dGVzQQAAbAJTZXRGaWxlVGltZQAUAUdldEZpbGVUaW1lAGQARW5kVXBk YXRlUmVzb3VyY2VBAAC0AlVwZGF0ZVJlc291cmNlQQCVAlNpemVvZlJlc291cmNlAADVAUxvY2tS ZXNvdXJjZQAAxwFMb2FkUmVzb3VyY2UAAKMARmluZFJlc291cmNlQQC0AEZyZWVMaWJyYXJ5AAwA QmVnaW5VcGRhdGVSZXNvdXJjZUEAAMMBTG9hZExpYnJhcnlFeEEAAFcARGVsZXRlRmlsZUEAYwFH ZXRUZW1wRmlsZU5hbWVBAABEAENyZWF0ZVByb2Nlc3NBAAAkAUdldE1vZHVsZUZpbGVOYW1lQQAA 9QBHZXRDdXJyZW50RGlyZWN0b3J5QQAAygBHZXRDb21tYW5kTGluZUEAZQFHZXRUZW1wUGF0aEEA AFkBR2V0U3lzdGVtRGlyZWN0b3J5QQB9AUdldFdpbmRvd3NEaXJlY3RvcnlBAAAmAUdldE1vZHVs ZUhhbmRsZUEAAHUBR2V0VmVyc2lvbkV4QQA+AUdldFByb2NBZGRyZXNzAADCAUxvYWRMaWJyYXJ5 QQAAXQFHZXRTeXN0ZW1UaW1lAH0ARXhpdFByb2Nlc3MAnQFIZWFwRGVzdHJveQAaAUdldExhc3RF cnJvcgAAmwFIZWFwQ3JlYXRlAADlAldyaXRlUHJpdmF0ZVByb2ZpbGVTdHJpbmdBAABLRVJORUwz Mi5kbGwAAFsBUmVnQ2xvc2VLZXkAewFSZWdRdWVyeVZhbHVlRXhBAAByAVJlZ09wZW5LZXlFeEEA ZwFSZWdFbnVtS2V5RXhBAF8BUmVnQ3JlYXRlS2V5RXhBAGIBUmVnRGVsZXRlS2V5QQBqAVJlZ0Vu dW1WYWx1ZUEAhgFSZWdTZXRWYWx1ZUV4QQAAegFSZWdRdWVyeVZhbHVlQQAAQURWQVBJMzIuZGxs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC4AAABTeXN0ZW1cQ3VycmVudENvbnRyb2xTZXRcU2VydmljZXNcVnhEXE1TVENQAE5hbWVTZXJ2 ZXIAAFNZU1RFTVxDdXJyZW50Q29udHJvbFNldFxTZXJ2aWNlc1xUY3BpcFxQYXJhbWV0ZXJzXElu dGVyZmFjZXNcAABTWVNURU1cQ3VycmVudENvbnRyb2xTZXRcU2VydmljZXNcVGNwaXBcUGFyYW1l dGVyc1xJbnRlcmZhY2VzAAAAQ29uY2VwdCBWaXJ1cyhDVikgVi42LCBDb3B5cmlnaHQoQykyMDAx LCAoVGhpcydzIENWLCBObyBOaW1kYS4pAE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6 IG11bHRpcGFydC9yZWxhdGVkOw0KCXR5cGU9Im11bHRpcGFydC9hbHRlcm5hdGl2ZSI7DQoJYm91 bmRhcnk9Ij09PT1fQUJDMTIzNDU2ajc4OTBERUZfPT09PSINClgtUHJpb3JpdHk6IDMNClgtTVNN YWlsLVByaW9yaXR5OiBOb3JtYWwNClgtVW5zZW50OiAxDQoNCi0tPT09PV9BQkMxMjM0NTZqNzg5 MERFRl89PT09DQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCglib3VuZGFy eT0iPT09PV9BQkMwOTg3Nmo1NDMyMURFRl89PT09Ig0KDQotLT09PT1fQUJDMDk4NzZqNTQzMjFE RUZfPT09PQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7DQoJY2hhcnNldD0iaXNvLTg4NTktMSIN CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCg0KDQo8SFRNTD48 SEVBRD48L0hFQUQ+PEJPRFkgYmdDb2xvcj0zRCNmZmZmZmY+DQo8aWZyYW1lIHNyYz0zRGNpZDpF QTRETUdCUDlwIGhlaWdodD0zRDAgd2lkdGg9M0QwPg0KPC9pZnJhbWU+PC9CT0RZPjwvSFRNTD4N Ci0tPT09PV9BQkMwOTg3Nmo1NDMyMURFRl89PT09LS0NCg0KLS09PT09X0FCQzEyMzQ1Nmo3ODkw REVGXz09PT0NCkNvbnRlbnQtVHlwZTogYXVkaW8veC13YXY7DQoJbmFtZT0ic2FtcGxlLmV4ZSIN CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NA0KQ29udGVudC1JRDogPEVBNERNR0JQ OXA+DQoNCgANCg0KLS09PT09X0FCQzEyMzQ1Nmo3ODkwREVGXz09PT0NCg0KAAAATlVMPQAAAAAN Cg0KW3JlbmFtZV0NCgAAXHdpbmluaXQuaW5pAAAAAEM6XABQZXJzb25hbAAAAABTb2Z0d2FyZVxN aWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxFeHBsb3JlclxTaGVsbCBGb2xkZXJzAAAA AFwAAAAuLgAAXCouKgAAAAAEAACAAgAAgEVYUExPUkVSAAAAAGZzZGhxaGVyd3FpMjAwMQBlZnFw bTIzMDBkZmhyb29wAAAAAFNZU1RFTVxDdXJyZW50Q29udHJvbFNldFxTZXJ2aWNlc1xsYW5tYW5z ZXJ2ZXJcU2hhcmVzXFNlY3VyaXR5AABzaGFyZSBjJD1jOlwAAAAAdXNlciBndWVzdCAiIgAAAGxv Y2FsZ3JvdXAgQWRtaW5pc3RyYXRvcnMgZ3Vlc3QgL2FkZAAAAABsb2NhbGdyb3VwIEd1ZXN0cyBn dWVzdCAvYWRkAAAAAHVzZXIgZ3Vlc3QgL2FjdGl2ZQAAb3BlbgAAAAB1c2VyIGd1ZXN0IC9hZGQA bmV0AEhpZGVGaWxlRXh0AFNob3dTdXBlckhpZGRlbgBIaWRkZW4AAFNvZnR3YXJlXE1pY3Jvc29m dFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXEV4cGxvcmVyXEFkdmFuY2VkACVscwBcXCVzAAAAACVs ZCAlbGQgJWxkACVsZCAlbGQASW1hZ2UgU3BhY2UgRXhlYyBXcml0ZSBDb3B5AEltYWdlIFNwYWNl IEV4ZWMgUmVhZC9Xcml0ZQBJbWFnZSBTcGFjZSBFeGVjIFJlYWQgT25seQAASW1hZ2UgU3BhY2Ug RXhlY3V0YWJsZQAASW1hZ2UgU3BhY2UgV3JpdGUgQ29weQAASW1hZ2UgU3BhY2UgUmVhZC9Xcml0 ZQAASW1hZ2UgU3BhY2UgUmVhZCBPbmx5AAAASW1hZ2UgU3BhY2UgTm8gQWNjZXNzAAAATWFwcGVk IFNwYWNlIEV4ZWMgV3JpdGUgQ29weQAAAABNYXBwZWQgU3BhY2UgRXhlYyBSZWFkL1dyaXRlAAAA AE1hcHBlZCBTcGFjZSBFeGVjIFJlYWQgT25seQBNYXBwZWQgU3BhY2UgRXhlY3V0YWJsZQBNYXBw ZWQgU3BhY2UgV3JpdGUgQ29weQBNYXBwZWQgU3BhY2UgUmVhZC9Xcml0ZQBNYXBwZWQgU3BhY2Ug UmVhZCBPbmx5AABNYXBwZWQgU3BhY2UgTm8gQWNjZXNzAABSZXNlcnZlZCBTcGFjZSBFeGVjIFdy aXRlIENvcHkAAFJlc2VydmVkIFNwYWNlIEV4ZWMgUmVhZC9Xcml0ZQAAUmVzZXJ2ZWQgU3BhY2Ug RXhlYyBSZWFkIE9ubHkAAABSZXNlcnZlZCBTcGFjZSBFeGVjdXRhYmxlAAAAUmVzZXJ2ZWQgU3Bh Y2UgV3JpdGUgQ29weQAAAFJlc2VydmVkIFNwYWNlIFJlYWQvV3JpdGUAAABSZXNlcnZlZCBTcGFj ZSBSZWFkIE9ubHkAAAAAUmVzZXJ2ZWQgU3BhY2UgTm8gQWNjZXNzAAAAAFByb2Nlc3MgQWRkcmVz cyBTcGFjZQAAAEV4ZWMgV3JpdGUgQ29weQBFeGVjIFJlYWQvV3JpdGUARXhlYyBSZWFkIE9ubHkA AEV4ZWN1dGFibGUAAFdyaXRlIENvcHkAAFJlYWQvV3JpdGUAAFJlYWQgT25seQAAAE5vIEFjY2Vz cwAAAEltYWdlAAAAVXNlciBQQwBUaHJlYWQgRGV0YWlscwAASUQgVGhyZWFkAAAAUHJpb3JpdHkg Q3VycmVudAAAAABDb250ZXh0IFN3aXRjaGVzL3NlYwAAAABTdGFydCBBZGRyZXNzAAAAVGhyZWFk AABQYWdlIEZhdWx0cy9zZWMAVmlydHVhbCBCeXRlcyBQZWFrAABWaXJ0dWFsIEJ5dGVzAAAAUHJp dmF0ZSBCeXRlcwAAAElEIFByb2Nlc3MAAEVsYXBzZWQgVGltZQAAAABQcmlvcml0eSBCYXNlAAAA V29ya2luZyBTZXQgUGVhawAAAABXb3JraW5nIFNldAAlIFVzZXIgVGltZQAlIFByaXZpbGVnZWQg VGltZQAAACUgUHJvY2Vzc29yIFRpbWUAAAAAUHJvY2VzcwBDb3VudGVyIDAwOQBzb2Z0d2FyZVxt aWNyb3NvZnRcd2luZG93cyBudFxjdXJyZW50dmVyc2lvblxwZXJmbGliXDAwOQAAAABDb3VudGVy cwAAAABWZXJzaW9uAExhc3QgQ291bnRlcgAAAABzb2Z0d2FyZVxtaWNyb3NvZnRcd2luZG93cyBu dFxjdXJyZW50dmVyc2lvblxwZXJmbGliAAAAAC9zY3JpcHRzAAAAAC9NU0FEQwAAL2MAAC9kAAAv c2NyaXB0cy8uLiUyNTVjLi4AAC9fdnRpX2Jpbi8uLiUyNTVjLi4vLi4lMjU1Yy4uLy4uJTI1NWMu LgAvX21lbV9iaW4vLi4lMjU1Yy4uLy4uJTI1NWMuLi8uLiUyNTVjLi4AL21zYWRjLy4uJTI1NWMu Li8uLiUyNTVjLi4vLi4lMjU1Yy8uLiVjMSUxYy4uLy4uJWMxJTFjLi4vLi4lYzElMWMuLgAvc2Ny aXB0cy8uLiVjMSUxYy4uAC9zY3JpcHRzLy4uJWMwJTJmLi4AL3NjcmlwdHMvLi4lYzAlYWYuLgAv c2NyaXB0cy8uLiVjMSU5Yy4uAC9zY3JpcHRzLy4uJSUzNSU2My4uAAAAAC9zY3JpcHRzLy4uJSUz NWMuLgAAL3NjcmlwdHMvLi4lMjUlMzUlNjMuLgAAL3NjcmlwdHMvLi4lMjUyZi4uAAAvcm9vdC5l eGU/L2MrAAAAL3dpbm50L3N5c3RlbTMyL2NtZC5leGU/L2MrAG5ldCUlMjB1c2UlJTIwXFwlc1xp cGMkJSUyMCIiJSUyMC91c2VyOiJndWVzdCIAAHRmdHAlJTIwLWklJTIwJXMlJTIwR0VUJSUyMGNv b2wuZGxsJSUyMABodHRwb2RiYy5kbGwAAAAAYzpcaHR0cG9kYmMuZGxsAGQ6XGh0dHBvZGJjLmRs bABlOlxodHRwb2RiYy5kbGwADQo8aHRtbD48c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij53 aW5kb3cub3BlbigicmVhZG1lLmVtbCIsIG51bGwsICJyZXNpemFibGU9bm8sdG9wPTYwMDAsbGVm dD02MDAwIik8L3NjcmlwdD48L2h0bWw+AAAAAC9odHRwb2RiYy5kbGwAAABkaXIAR0VUICVzIEhU VFAvMS4wDQpIb3N0OiB3d3cNCkNvbm5uZWN0aW9uOiBjbG9zZQ0KDQoAAGM6AAByZWFkbWUAAG1h aW4AAAAAaW5kZXgAAABkZWZhdWx0AGh0bWwAAAAALmFzcAAAAAAuaHRtAAAAAFxyZWFkbWUuZW1s AC5leGUAAAAAbWVwAHdpbnppcDMyLmV4ZQAAAAByaWNoZWQyMC5kbGwAAAAALm53cwAAAAAuZW1s AAAAAC5kb2MAAAAAIC5leGUAAABkb250cnVub2xkAABpb2N0bHNvY2tldABnZXRob3N0YnluYW1l AAAAZ2V0aG9zdG5hbWUAaW5ldF9udG9hAAAAaW5ldF9hZGRyAAAAbnRvaGwAAABodG9ubAAAAG50 b2hzAAAAaHRvbnMAAABjbG9zZXNvY2tldABzZWxlY3QAAHNlbmR0bwAAc2VuZAAAAAByZWN2ZnJv bQAAAAByZWN2AAAAAGJpbmQAAAAAY29ubmVjdABzb2NrZXQAAF9fV1NBRkRJc1NldAAAAABXU0FD bGVhbnVwAABXU0FTdGFydHVwAAB3czJfMzIuZGxsAABNQVBJTG9nb2ZmAABNQVBJU2VuZE1haWwA AAAATUFQSUZyZWVCdWZmZXIAAE1BUElSZWFkTWFpbAAAAABNQVBJRmluZE5leHQAAAAATUFQSVJl c29sdmVOYW1lAE1BUElMb2dvbgAAAE1BUEkzMi5ETEwAAFdOZXRBZGRDb25uZWN0aW9uMkEAV05l dENhbmNlbENvbm5lY3Rpb24yQQAAV05ldE9wZW5FbnVtQQAAAFdOZXRFbnVtUmVzb3VyY2VBAAAA V05ldENsb3NlRW51bQAAAE1QUi5ETEwAU2hlbGxFeGVjdXRlQQAAAFNIRUxMMzIuRExMAFJlZ2lz dGVyU2VydmljZVByb2Nlc3MAAFZpcnR1YWxGcmVlRXgAAABWaXJ0dWFsUXVlcnlFeAAAVmlydHVh bEFsbG9jRXgAAFZpcnR1YWxQcm90ZWN0RXgAAAAAQ3JlYXRlUmVtb3RlVGhyZWFkAABIZWFwQ29t cGFjdABIZWFwRnJlZQAAAABIZWFwQWxsb2MAAABIZWFwRGVzdHJveQBIZWFwQ3JlYXRlAABLRVJO RUwzMi5ETEwAAAAAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25cQXBw IFBhdGhzXAAAAABTT0ZUV0FSRVxNaWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxBcHAg UGF0aHMAVHlwZQAAAABSZW1hcmsAAFg6XABTT0ZUV0FSRVxNaWNyb3NvZnRcV2luZG93c1xDdXJy ZW50VmVyc2lvblxOZXR3b3JrXExhbk1hblxYJABQYXJtMmVuYwAAAABQYXJtMWVuYwAAAABGbGFn cwAAAFBhdGgAAAAAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25cTmV0 d29ya1xMYW5NYW5cAAAAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25c TmV0d29ya1xMYW5NYW4AAAAAU1lTVEVNXEN1cnJlbnRDb250cm9sU2V0XFNlcnZpY2VzXGxhbm1h bnNlcnZlclxTaGFyZXMAAAANCgAAQ2FjaGUAAABTb2Z0d2FyZVxNaWNyb3NvZnRcV2luZG93c1xD dXJyZW50VmVyc2lvblxFeHBsb3JlclxNYXBNYWlsAABRVUlUDQoAAC4NCgBTdWJqZWN0OiAAAABG cm9tOiA8AERBVEENCgAAUkNQVCBUTzogPAAAPg0KAE1BSUwgRlJPTTogPAAAAABIRUxPIAAAAGFh YmJjYwAAZTpcaHR0cG9kYmMuZGxsAGQ6XGh0dHBvZGJjLmRsbABjOlxodHRwb2RiYy5kbGwAIC1k b250cnVub2xkAAAAAE5VTEwAAAAAXHNhbXBsZSouZXhlAAAAAGh0dHBvZGJjLmRsbAAAAABiaW5k ZXMzOXFwAAAgLWJpbmRlczM5cXAAAAAAXENTUlNTLkVYRQAAXHJpY2hlZDIwLmRsbAAAAGJvb3QA AAAAU2hlbGwAAABleHBsb3Jlci5leGUgbG9hZC5leGUgLWRvbnRydW5vbGQAAABcc3lzdGVtLmlu aQBcbG9hZC5leGUAAABcXAAAb2N0ZXQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAMAAwAAACgAAIAKAAAAYAAA gA4AAAB4AACAAAAAAAAAAAAEAAAAAAAFAAEAAACQAACAAgAAAKgAAIADAAAAwAAAgAQAAADYAACA BQAAAPAAAIAAAAAAAAAAAAQAAAAAAAEAZgAAAAgBAIAAAAAAAAAAAAQAAAAAAAEAZQAAACABAIAA AAAAAAAAAAQAAAAAAAEABAgAADgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAEgBAAAAAAAAAAAAAAQA AAAAAAEABAgAAFgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAGgBAAAAAAAAAAAAAAQAAAAAAAEABAgA AHgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAIgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAJgBAACo4QAA KAEAAOQEAAAAAAAA0OIAAOgCAADkBAAAAAAAALjlAACoCAAA5AQAAAAAAABg7gAAqA4AAOQEAAAA AAAACP0AADABAADkBAAAAAAAADj+AAABAAAA5AQAAAAAAAA8/gAATAAAAOQEAAAAAAAAKAAAABAA AAAgAAAAAQAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACA AICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAB3d3d3d3cAAHiIiIiIhw AMcP+I+IiHAMAAZm+PiIcDxMzMxvj4hwd0zIjMb4iHB3bG///4+IcAeMZmZm+IhwBHhv/Ob/iHAA R4zOb/+HcAAEZmb8+HdwAAcP9m/3AAAABw////cHAAAHAAAAB3AAAAd3d3d3AAAAAAAAAAAAAOAB gADgAQCAyAH//6AB//gAAQAAAAEAgAAB//+AAf/4gAEAAMABAIDgAf//6AH/+OgLAADv5wCA4A8A AP//AAgoAAAAIAAAAEAAAAABAAQAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAA AICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAA AAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIiIgAAAAAh3d3d3d3d3d3d3d4AAAAAI////f3d3d3d3d3 eAAAAACA////d/f3d3d3d3gAAAAAgP////9/f393d3d4AAAEzMD///////f393d3eAAATACMBMZm b////393d3gAAEwAAMZszMZv//f393d4AAjEBExszMzMxv//f3d3eAAIZETGzGZszMxv//d3d3gA CDZMZsb//MzGxv//d3d4AAiMxGxv//9MZub/9/d3eAAIg2xsb/////////9/d3gACHiGbGZmZmZm Zv///3d4AACHhszMzGZu7ub///f3eAAAyHzGZmZmZu7m////d3gAAASHxm///0bu5v////d4AAAM SHxm//Rmfm////93eAAAAMaHZszGbu5v////93gAAAAMZnzMxubm//////94AAAAAMbMzMxub/z/ ///3eAAAAACAZmZmZv/2////d4gAAAAAgP//Zm//YP//93iIAAAAAID///9mZv///3eIiAAAAACA //////////gAAAAAAAAAgP/////////4B3iAAAAAAID/////////+HeIAAAAAACA//////////h4 gAAAAAAAgP/////////4iAAAAAAAAIAAAAAAAAAACIAAAAAAAACIiIiIiIiIiIgAAAAA//////wA AAP8AAAD/AAAA/0AAAP9AAAD4QAAA8wAAAPMAAADiAAAA4AAAAOAAAADgAAAA4AAAAOAAAADwAAA A8AAAAPgAAAD4AAAA/AAAAP4AAAD/AAAA/0AAAP9ABAD/QAAA/0AAAP9AACH/QAAD/0AAB/9AAA/ /f/+f/wAAP8oAAAAIAAAAEAAAAABAAgAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA gAAAAICAAIAAAACAAIAAgIAAAMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIi IgApKSkAVVVVAE1NTQBCQkIAOTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABm AAAAmQAAAMwAADMAAAAzMwAAM2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8A AJkAAACZMwAAmWYAAJmZAACZzAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA /8wAMwAAADMAMwAzAGYAMwCZADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNm MwAzZmYAM2aZADNmzAAzZv8AM5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZ ADPMzAAzzP8AM/8zADP/ZgAz/5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAA ZjMzAGYzZgBmM5kAZjPMAGYz/wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZmQBm mcwAZpn/AGbMAABmzDMAZsyZAGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkz mQCZAJkAmQDMAJkAAACZMzMAmQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkz AJmZZgCZmZkAmZnMAJmZ/wCZzAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kA mf/MAJn//wDMAAAAmQAzAMwAZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADM ZjMAmWZmAMxmmQDMZswAmWb/AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzM mQDMzMwAzMz/AMz/AADM/zMAmf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNm AP8zmQD/M8wA/zP/AP9mAAD/ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA /5n/AP/MAAD/zDMA/8xmAP/MmQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/ ZmYA/2b/AP//ZgAhAKUAX19fAHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx 8QD4+PgA8Pv/AKSgoACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK6xISEhISEhISEhISEhISEhISEhISEhISCgoKCgoK CgrrvLy8vLy8vLy8vLy8vLy8vLy8vLy8vBIKCgoKCgoKCuvz8/Pz8/Mb8xsbGxsbGxsbGxsbGxu8 EgoKCgoKCgoK6wr09PTz9PMbG/Mb8xsbGxsbGxsbG7wSCgoKCgoKCgrrCvb09vTz9PPzG/Mb8xvz GxsbGxsbvBIKCgoKCgSnp6cK9Pb09vTz9PTz8/Mb8xvzGxsbGxu8EgoKCgoEpwoK66cKhaeKioqK 8/Tz9PPz8xvzGxsbG7wSCgoKCgSnCgoKCqeLrM7Ozs6KivTz9PMb8xvzGxsbvBIKCgrrpwQKZoan i87Ozs7Ozs7OivTz9PMb8xsbGxu8EgoKCuqtpmaFp4vOzqysrM7Ozs7OivTz8/MbGxsbG7wSCgoK 6gOthqeLrM6s9vb2p87OzrLOivTz8/MbGxsbvBIKCgrqc86nhovOrPb29vb2hc6ystOK8/TzG/Mb Gxu8EgoKCut0A62ni86s9vb29vb29vb29vP08/TzG/MbG7wSCgoK65l0z4uszqysrKysrKysrKys rPT09PPz8xsbvBIKCgoK65ntrM7Ozs7OzrOzs9PT09Os9vTz9PMb8xu8EgoKCgqnc5rOzqysrKys rKysrNnZ06z09PTz8/MbG7wSCgoKCgqGkaDOrKz29vb29oWs6NnTrPb09PTz8/MbvBIKCgoKCqeG kaDOrKz29vaFrLPh6Kz29Pb08/TzGxu8EgoKCgoKCqestO+srKenp6yz2ejTrPb29PT08/PzG7wS CgoKCgoKCqesrLvOzs7Os9Oz06z29vT29PT08/PzvBIKCgoKCgoKCqeszs7Ozs7Os9Os9vbO9vT2 9PTz87wHEgoKCgoKCgoK6wqsrKysrKysrPb29qz29vT09PO8B5ISCgoKCgoKCgrrCvb29vasrKz2 9vasCvb09vTzvAeSkhIKCgoKCgoKCusK9vb29vb2rKysrPb29vb087wHkpLrEgoKCgoKCgoK6wr2 9vb29vb29vb29vb29vYSQ0NDQ0NDCgoKCgoKCgrrCvb29vb29vb29vb29vb29pIKG7ySEgoKCgoK CgoKCusK9vb29vb29vb29vb29vb2khu8khIKCgoKCgoKCgoK6wr29vb29vb29vb29vb29vaSvJIS CgoKCgoKCgoKCgrrCvb29vb29vb29vb29vb29pKSEgoKCgoKCgoKCgoKCusKCgoKCgoKCgoKCgoK CgoKkhIKCgoKCgoKCgoKCgoK6+zs7Ozs7Ozs7Ozs7Ozs7OzsCgoKCgoKCgr//////AAAA/wAAAP8 AAAD/QAAA/0AAAPhAAADzAAAA8wAAAOIAAADgAAAA4AAAAOAAAADgAAAA4AAAAPAAAADwAAAA+AA AAPgAAAD8AAAA/gAAAP8AAAD/QAAA/0AEAP9AAAD/QAAA/0AAIf9AAAP/QAAH/0AAD/9//5//AAA /ygAAAAwAAAAYAAAAAEACAAAAAAAAAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAMDcwADwyqYABAQEAAgICAAMDAwAERERABYWFgAcHBwAIiIiACkpKQBV VVUATU1NAEJCQgA5OTkAgHz/AFBQ/wCTANYA/+zMAMbW7wDW5+cAkKmtAAAAMwAAAGYAAACZAAAA zAAAMwAAADMzAAAzZgAAM5kAADPMAAAz/wAAZgAAAGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkz AACZZgAAmZkAAJnMAACZ/wAAzAAAAMwzAADMZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAA MwAzADMAZgAzAJkAMwDMADMA/wAzMwAAMzMzADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAz ZpkAM2bMADNm/wAzmQAAM5kzADOZZgAzmZkAM5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM /wAz/zMAM/9mADP/mQAz/8wAM///AGYAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNm AGYzmQBmM8wAZjP/AGZmAABmZjMAZmZmAGZmmQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZzABmmf8A ZswAAGbMMwBmzJkAZszMAGbM/wBm/wAAZv8zAGb/mQBm/8wAzAD/AP8AzACZmQAAmTOZAJkAmQCZ AMwAmQAAAJkzMwCZAGYAmTPMAJkA/wCZZgAAmWYzAJkzZgCZZpkAmWbMAJkz/wCZmTMAmZlmAJmZ mQCZmcwAmZn/AJnMAACZzDMAZsxmAJnMmQCZzMwAmcz/AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf// AMwAAACZADMAzABmAMwAmQDMAMwAmTMAAMwzMwDMM2YAzDOZAMwzzADMM/8AzGYAAMxmMwCZZmYA zGaZAMxmzACZZv8AzJkAAMyZMwDMmWYAzJmZAMyZzADMmf8AzMwAAMzMMwDMzGYAzMyZAMzMzADM zP8AzP8AAMz/MwCZ/2YAzP+ZAMz/zADM//8AzAAzAP8AZgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8z zAD/M/8A/2YAAP9mMwDMZmYA/2aZAP9mzADMZv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wA AP/MMwD/zGYA/8yZAP/MzAD/zP8A//8zAMz/ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A //9mACEApQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4+ADw +/8ApKCgAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8ACgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgrrEhISEhISEhISEhISEhISEhIS EhISEhISEhISEhISEhISEhISCgoKCgoKCgoKCgrrEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhISEhISCgoKCgoKCgoKCgrrvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vBIS CgoKCgoKCgoKCgrr8/Pz8/Pz8/Pz8xvz8xsbGxsbGxsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoK Cgrr8/Pz8/Pz8/Pz8xvz8xsbGxsbGxsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoKCgrrCgr09PT0 9PP09PMbGxvz8xvz8xsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoKCgrrCgr09PT09PP09PMbGxvz 8xvz8xsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoKCgrrCgr29PT29vTz8/Tz8/MbG/MbG/MbG/Pz GxsbGxsbGxsbvBISCgoKCgoKBASnp6enCgr09vb09Pb09PP09PTz8/Pz8xvz8xsb8xsbGxsbGxsb vBISCgoKCgoKBASnp6enCgr09vb09Pb09PP09PTz8/Pz8xvz8xsb8xsbGxsbGxsbvBISCgoKCgoE p6cKCgrrp6cKhYWnp4qKioqKivP09PP09PPz8/PzG/PzGxsbGxsbvBISCgoKCgoEp6cKCgoKCgqn i4usrM7Ozs7OzoqKivTz8/Tz8xsb8xsb8xsbGxsbvBISCgoK6+unBAQKZmaGp6eLzs7Ozs7Ozs7O zs7Ozor09PP09PPzG/PzGxsbGxsbvBISCgoK6+unBAQKZmaGp6eLzs7Ozs7Ozs7Ozs7Ozor09PP0 9PPzG/PzGxsbGxsbvBISCgoK6uqtpqZmhYWni4vOzs6srKysrM7Ozs7Ozs6KivTz8/Pz8xsbGxsb GxsbvBISCgoK6uoDra2Gp6eLrKzOrKz29vb29qfOzs7OzrLOzor09PPz8/PzGxsbGxsbvBISCgoK 6upzzs6nhoaLzs6s9vb29vb29vaFhc6ysrLT04rz8/T08xsb8xsbGxsbvBISCgoK6upzzs6nhoaL zs6s9vb29vb29vaFhc6ysrLT04rz8/T08xsb8xsbGxsbvBISCgoK6+t0AwOtp6eLzs6s9vb29vb2 9vb29vb29vb29vP09PPz9PPzG/PzGxsbvBISCgoK6+uZdHTPi4uszs6srKysrKysrKysrKysrKys rKz09PT09PPz8/PzGxsbvBISCgoKCgrrmZntrKzOzs7Ozs7Ozs6zs7Ozs9PT09PT06z29vT08/T0 8xsb8xsbvBISCgoKCgrrmZntrKzOzs7Ozs7Ozs6zs7Ozs9PT09PT06z29vT08/T08xsb8xsbvBIS CgoKCgqnc3Oazs7OrKysrKysrKysrKysrKzZ2dnT06z09PT09PPz8/PzGxsbvBISCgoKCgqnc3Oa zs7OrKysrKysrKysrKysrKzZ2dnT06z09PT09PPz8/PzGxsbvBISCgoKCgoKhoaRoKDOrKys9vb2 9vb29vaFhazo6NnT06z29vT09PT08/Pz8xsbvBISCgoKCgoKp6eGkZGgzs6srKz29vb29oWsrLPh 4eisrPb09Pb29PPz9PPzGxsbvBISCgoKCgoKp6eGkZGgzs6srKz29vb29oWsrLPh4eisrPb09Pb2 9PPz9PPzGxsbvBISCgoKCgoKCgqnrKy07++srKynp6enp6yzs9no6NOsrPb29vT09PT08/Pz8xsb vBISCgoKCgoKCgoKp6esrKy7zs7Ozs7OzrPT07PT06z29vb09Pb29PT09PPz8/PzvBISCgoKCgoK CgoKCgqnrKzOzs7Ozs7Ozs6zs9OsrPb29s729vT09vT09PPz87y8BxISCgoKCgoKCgoKCgqnrKzO zs7Ozs7Ozs6zs9OsrPb29s729vT09vT09PPz87y8BxISCgoKCgoKCgoKCgrrCgqsrKysrKysrKys rKz29vb29qz29vb29PT09PPzvAcHkhISCgoKCgoKCgoKCgrrCgr29vb29vasrKysrPb29vasrAr2 9vT09vT087y8B5KSkhISCgoKCgoKCgoKCgrrCgr29vb29vb29vasrKysrKz29vb29vb29PPzvAcH kpKS6xISCgoKCgoKCgoKCgrrCgr29vb29vb29vasrKysrKz29vb29vb29PPzvAcHkpKS6xISCgoK CgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29hISQ0NDQ0NDQ0NDCgoKCgoKCgoKCgrr Cgr29vb29vb29vb29vb29vb29vb29vb29pKSChsbvJKSEgoKCgoKCgoKCgoKCgrrCgr29vb29vb2 9vb29vb29vb29vb29vb29pKSChsbvJKSEgoKCgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb2 9vb29vb29pKSG7y8khISCgoKCgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKS vJKSEgoKCgoKCgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKSkhISCgoKCgoK CgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKSkhISCgoKCgoKCgoKCgoKCgoK CgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKSkhISCgoKCgoKCgoKCgoKCgoKCgrrCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCpKSEgoKCgoKCgoKCgoKCgoKCgoKCgrr7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7OzsCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoK////////SUz/AAAAAAdGSf8AAAAAB3hF/wAAAAAHAEn/AAAAAAdfTf8AAAAAB0Ux/2AA AAAHMUb/YAAAAAdfRv9gAAAAB1Vf4GAAAAAHeEXgYAAAAAcASccAAAAAB19DxwAAAAAHeEUEAAAA AAcASQQAAAAAB19DAAAAAAAHTEwAAAAAAAcxAAAAAAAAB0VEAAAAAAAHWQAAAAAAAAcAAQAAAAAA B0RJwAAAAAAHMHjAAAAAAAcAAMAAAAAAB1RfwAAAAAAHeEXgAAAAAAcASeAAAAAAB19Q4AAAAAAH eEX4AAAAAAcASfwAAAAAB19Q/wAAAAAHSU7/AAAAAAcyNv9gAAAAB19F/2AACAAHU1T/YAAAAAdJ Qf9gAAAABzI3/2AAAAAHX0X/YAAACB9QRf9gAAAIHzEy/2AAAAA/RF//YAAAAP9FUP9gAAAB/3hF /2AAAAH/AEn/YAAAAf9fU/9////H/0FM/wAAAA//MkH///////9fRf///////0RPKAAAACAAAABA AAAAAQABAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// /AAAA/3///v9///7/f//+/3///vh///7zAH/+8wAf/uIAD/7gAAf+4A4T/ugfO/7oH//+7AAD/vY D+/72ADv++x87/vmOd/78wPf+/iHv/v8A2/7/QDv+/3x3/v9/D/z/f/+A/3///f9///v/f//3/3/ /7/9//9//f///05QQUQAAAEABQAQEBAAAQAEACgBAAABACAgEAABAAQA6AIAAAIAICAAAAEACACo CAAAAwAwMAAAAQAIAKgOAAAEACAgAgABAAEAMAEAAAUAUEFERElOR1hYUEFERElOR1BBRERJTkdY WFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQ QURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQ QURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFE RElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFE RElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJ TkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJ TkdQQURESU5HWAAQAAA4AQAAJTBDMFEwXzBtMJwwqDDnMPYwCjEVMSYxZzGGMaAx2DHvMQcyaTJz MoEylDKxMsIy/DJJM1YzZDNzM58zETQZNG00mDThNGk1gDXKNeM1+jURNlk2fjaJNp42yjYCNx83 LjdIN3s3nDeoN7E3xjfRN+43/TcdOD44SjhgOGU4qDi2OMk42jj/OBY5ITlAOVc5kzm4Oc459TkB OiE6WzpkOm86kjqkOr86yDrfOvA6CDsZO087VTtrO387iTudO7k7xjvhOwo8gTyWPKM8ujzePO48 Jj0yPTg9RT1PPV49aj2JPac90j33PQw+Ij4pPi4+RT5ePo8+nT6/PtA+1T7ePuk+8z76PhY/HT8m PzQ/Oz9BP0k/WD9fP2g/hz+NP5Q/oD+uP7o/2D/hP+k/+D8AAAAgAAD4AQAADTAbMCowMjA6ME4w kTCcMKwwtTDJMNow7zD1MAIxBzEMMRUxHDElMSwxNTE8MUUxTDFVMWQxfDGBMYgxqDG9Mcox/DEy MlYypTKrMr0yzzILMzgzPzNeM2wzvzMDNAo0JDQ5NEQ0SjRcNGQ0bjR6NIA0hzSQNJY0szS5NNI0 4jTnNPc0/DQMNRE1IjUnNTc1PDVPNVQ1ZTVqNXs1gDWQNZU1pTWqNbo1vzXSNdc15zXsNfw1ATYR NhY2JzY3Njw2TzZUNmQ2aTZ6Nos2mzagNrA2tTbINs023TbiNvI29zYHNww3HDchNzE3NjdJN043 XjdjN3M3eDeIN403nTeiN7I3tzfKN8833zfkN/Q3+TcJOA44HjgjODM4ODhLOFA4YDhlOHU4ejiK OI84nzikOLQ4uTjMONE44TjmOPY4+zgLORA5IDklOTU5OjlNOVI5YjlnOXc5fDmMOZE5oTmmObc5 vTnCOcg5zTnSOd054znpOe458zkBOgc7FDtDO0w7ajtzO4E7ijuiO647zzsBPB48XzxvPLE85DwI PRc9Jz0/PZU9nT2+PcQ9yj3QPdw95z3tPfQ9+j0QPj0+YD6JPpQ+sj7HPtE+2D7fPuY+7T70Pvs+ Aj8JPxA/Fz8ePyU/LD8zPzo/XD9jP3w/9D/7PwAwAAA4AQAAFDAnMDIwPjBKMGMwiDCPMCYxqzG8 Md0x8jEoMkcyYjJ/Mroy0TLiMvUyOzNUM3YziTPQM9Yz7DP+Mwg0GjQ2NEE0TTRgNIY0ljTXNPc0 FzU3NUk1WzVtNXw1rjW9Ncg14TXuNfQ1OTY/NlM2cjZ5Nog2jjawNtg27TYGNyk3SjdcN2E3rDe5 N8M3yTfpN/M3DjgYOB44JjgsODg4RThROFc4fDjNOPA4AzkROSQ5PTlUOV85ZDlqOX05hjmZOZ85 tznBOds57jkJOh46LTpCOio7NDupOyo8RTxPPF08cDx2PIk8nzyuPLU8xDzmPPY8BT0NPRM9Ij0o PUI9Xz14PZU9nz2lPbw9zj31PQY+Hj4yPjw+UD5hPmc+eT6GPqE+yj4RPzY/Rj9nP4U/sz/YPwBA AABcAgAABjApMD4wSzBiMIYwljDFMM8w1TDbMEIxRzFNMWExZzF0MX8xhjGPMakxxDHUMeUx+jH/ MRAyOzJAMkYyUTJlMnAykTKsMrUyvDLvMv8yBjM+M08zZjNsM3szlDOdM7szxjPiM/kzADQcNCI0 NDRJNFs0cTSGNJM0mTSuNLs05DTqNPQ0BTULNRI1JjU2NVQ1XTVwNXY1mzWhNbk1zzXWNec1+DX+ NQk2FzY6Nmw2kTbMNgY3ODddN6M3rje0N9034zf7NxA4FTg2OFM4WjhnOHQ4jTidOKU4xDjUONo4 +zgCOQ45FDkrOTg5RjlOOVM5YjlqOXY5fjmKOZI5nzmlObA5uTnQOdw58Dn5OQw6SDpZOmM6aDpx On06gjqKOo86lTqcOqE6pzquOrM6uTrAOsU6yzrTOtk64DrmOu068jr4Ov86BDsKOxE7FjscOyM7 KDsuOzU7PDtCO0k7TjtXO2U7bTtyO3s7gjuKO487lTucO6E7pzuuO7M7uTvAO8U7yzvSO9c74Dvn O+879Dv6OwE8BjwMPBM8GDwePCU8KjwwPDc8PDxCPEk8TjxUPFs8YDxpPHQ8fDyBPIc8jjyTPJk8 oDylPKs8sjy3PL08xDzJPM881jzbPOE86DztPPM8+jz/PAU9DD0RPRc9Hj0jPSk9MD01PTs9Qj1H PU09VD1ZPV89Zj1rPXE9eD19PYM9ij2PPZU9nD2hPac9rj2zPbk9wD3FPcs90j3XPd095D3vPfY9 Aj4OPho+Jj5CPlQ+cD6cPvA+9j4OPzs/VD9wP4I/kz8AUAAAOAEAAGAwazCAMJ4wvjD2MBMxIzEx MUAxTzFqMaEx0DHdMfUxCzIaMiwyOzJMMl0yczKKMrAyvzLNMtMy6jL1Mv0yODM+M1AzLTRHNFA0 ZjRsNHU0xjT7NAk1IDUxNVM1aDV4NYE1lTWfNc012DXwNfk1AjY0Njo2TDZvNnk2izamNrE2yjb8 NjY3VjeIN7Y3yDfUN9o3DTgcODc4PThLOGA4azh4OC45NDlQOV05djmWOdg53jnoOfk5EzofOig6 OTpdOmM6bDp0On46hzqTOps6ojq0Oro6wzrqOhM7KTthO3I7lTuvO8A79jsTPCk8NDx0PH88kTzY PDQ9dD2fPc89FT4bPjE+QD5RPlc+dz6EPow+kj6dPrg+wD7LPgs/Nz9DP1s/ZD99P4U/lj+/P+A/ 6j8AYAAArAEAABswQDAAMQYxIjFEMVoxdDF9McExxzHRMekxiDKhMroyJTM8M1QzhDOKM5EzqTO6 M8AzyDPXM/kz/zMFNBQ0JDQqNDU0VzRdNGg0bjR8NIQ0izSQNJY0rDSzNLo01TTgNOY0+DQFNQw1 FTUeNSY1LjU9NUM1STVVNXw1kTWZNaU1rTW8Nck1zzXaNeM18DX2Nfs1ATYHNgw2EjZFNkw2VzZ0 NsE25jYONxc3HDciNyk3Ljc9N0M3TzdXN1w3fDeIN6s3wDfLN9k34zfxN/s3BjgROC84NDg6OEU4 SzhcOGg4bTiOOJk4njilOKo4sDi2ONQ46jj2OAA5CjkiOT45TTlXOWw5czmZOZ85rjm3Ock50znl Ofc5/TkIOhg6ODpHOlM6WTpjOoI62jroOhk7WTthO2k7ezuLO5E7wDvZO/Y7DzxVPGY8dDyBPIw8 kzyyPMQ80jzpPO889TwMPRo9Lz00PTk9Pz1LPVk9fj2EPcw95D3qPQE+Nj5DPlk+aD6pPq8+xT7L PtQ+9j4GPw4/Jz9uP3Y/jj+VP6A/pz/NP9g/5z//PwBwAACcAAAACjBBMGYwyTDRMOow8DD1MBox IDEzMUExSDFOMVQxWjFzMXoxhzGeMbcxvTHRMesx+zEkMnYylTKzMscy5jIEMz0zVDNsM3gzijOc M8czzjPWM9wz4TPmMxg0HjQkNCo0OjRANEY0TDRSNFg0ZjRuNHQ0fzSMNJQ0ojSnNKw0sTS8NMk0 0zToNPQ0+jQcNS41ijWmNQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA= --====_ABC123456j7890DEF_==== --====_ABC123456j7890DEF_====-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 15 13:54:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09500; Tue, 15 Jan 2002 13:54:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18101; Tue, 15 Jan 2002 13:51:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18076 for ; Tue, 15 Jan 2002 13:51:45 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09343 for ; Tue, 15 Jan 2002 13:51:37 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0FIp9J06500 for ; Tue, 15 Jan 2002 12:51:09 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0FIp8H22159 for ; Tue, 15 Jan 2002 12:51:08 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jan 15 12:51:08 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 12:51:08 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD87@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Date: Tue, 15 Jan 2002 12:51:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DF5.96C4C1F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19DF5.96C4C1F0 Content-Type: text/plain; charset="iso-8859-1" How about defining the option format? I'd suggest we base this more on the Classless Static Routes option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ROUTES | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . route-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where route-data is one or more of a sequence of route table entries in the following format: 1 byte byte 16 byte destination address Where is the minimum number of bytes required to represent bits of the . A /64 prefix has the following format: 1 byte prefix (value of 64), 8-bytes of the prefix, followed by 16 bytes destination address. - Bernie Volz -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, January 15, 2002 9:36 AM To: dhcwg@ietf.org Subject: [dhcwg] static route option for dhcpv6 I have gone through the dhcpv6 22 spec. I felt that, static route option (option 33 in RFC 2132) is missing. which is useful for routing. Can we include this option also in the spec? thanks and regards Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C19DF5.96C4C1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] static route option for dhcpv6

How about defining the option format?

I'd suggest we base this more on the Classless Static = Routes option.

    = 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
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |          = OPTION_ROUTES        = |            = ; option-len        |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = .           &nbs= p;           &nbs= p;   = route-data          &n= bsp;           &n= bsp;   .
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Where route-data is one or more of a sequence of = route table entries
in the following format:

        1 byte = <prefix-length>
        <n> = byte <prefix address>
        16 byte = destination address

Where <n> is the minimum number of bytes = required to represent
<prefix-length> bits of the <prefix = address>.

A /64 prefix has the following format: 1 byte prefix = (value of 64),
8-bytes of the prefix, followed by 16 bytes = destination address.

- Bernie Volz


-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, January 15, 2002 9:36 AM
To: dhcwg@ietf.org
Subject: [dhcwg] static route option for = dhcpv6


I have gone through the dhcpv6 22 spec.
I felt that, static route option (option 33 in RFC = 2132) is missing.
which is useful for routing. Can we include this = option
also in the spec?
thanks and regards
Vijay



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C19DF5.96C4C1F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 03:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02574; Wed, 16 Jan 2002 03:21:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21451; Wed, 16 Jan 2002 03:19:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21424 for ; Wed, 16 Jan 2002 03:19:52 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02565 for ; Wed, 16 Jan 2002 03:19:49 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0G8JfH49639; Wed, 16 Jan 2002 09:19:49 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 21F03C052; Wed, 16 Jan 2002 09:19:05 +0100 (CET) Date: Wed, 16 Jan 2002 09:34:30 +0100 From: Martin Stiemerling To: vijayak@india.hp.com, dhcwg@ietf.org Subject: Re: [dhcwg] static route option for dhcpv6 Message-ID: <8550000.1011170070@elgar> In-Reply-To: <001301c19dd1$f1acbd80$2f290a0f@india.hp.com> References: <001301c19dd1$f1acbd80$2f290a0f@india.hp.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi Vijay, why do you think a static route option is needed at all? For the sake of autoconfiguration it is better to keep the routing information in the routers and to provide only a default router to the host (which is done through the router advertisements). In the case that the router is not the best choice for a specific route, the router will send an ICMP redirect message to the corresponding host, to inform about a better router for this route. Regards Martin --On Dienstag, Januar 15, 2002 20:05:56 +0530 Vijayabhaskar A K wrote: > I have gone through the dhcpv6 22 spec. > I felt that, static route option (option 33 in RFC 2132) is missing. > which is useful for routing. Can we include this option > also in the spec? > thanks and regards > Vijay > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 03:54:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02909; Wed, 16 Jan 2002 03:54:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22325; Wed, 16 Jan 2002 03:53:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22299 for ; Wed, 16 Jan 2002 03:53:16 -0500 (EST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02878 for ; Wed, 16 Jan 2002 03:53:13 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel6.hp.com (Postfix) with ESMTP id CBD3060062C; Wed, 16 Jan 2002 03:52:40 -0500 (EST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id OAA16934; Wed, 16 Jan 2002 14:18:23 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Martin Stiemerling'" , Subject: RE: [dhcwg] static route option for dhcpv6 Date: Wed, 16 Jan 2002 14:23:30 +0530 Message-ID: <001a01c19e6b$45f3cf20$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <8550000.1011170070@elgar> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi Martin, RFC for autoconf says that, in the absence of router, the host must use DHCP. In this case, the static route option will be very much helpful, for configuring the routes. Regards Vijay > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Wednesday, January 16, 2002 2:05 PM > To: vijayak@india.hp.com; dhcwg@ietf.org > Subject: Re: [dhcwg] static route option for dhcpv6 > > > Hi Vijay, > > why do you think a static route option is needed at all? > For the sake of autoconfiguration it is better to keep the routing > information in the routers and to provide only a default > router to the host > (which is done through the router advertisements). In the > case that the > router is not the best choice for a specific route, the > router will send > an ICMP redirect message to the corresponding host, to inform about a > better router for this route. > > Regards > Martin > > > --On Dienstag, Januar 15, 2002 20:05:56 +0530 Vijayabhaskar A K > wrote: > > > I have gone through the dhcpv6 22 spec. > > I felt that, static route option (option 33 in RFC 2132) is missing. > > which is useful for routing. Can we include this option > > also in the spec? > > thanks and regards > > Vijay > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 05:27:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03709; Wed, 16 Jan 2002 05:27:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25115; Wed, 16 Jan 2002 05:26:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25094 for ; Wed, 16 Jan 2002 05:26:01 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03705 for ; Wed, 16 Jan 2002 05:25:56 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0GAPvH50357; Wed, 16 Jan 2002 11:25:57 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 4B5ECC052; Wed, 16 Jan 2002 11:25:29 +0100 (CET) Date: Wed, 16 Jan 2002 11:40:53 +0100 From: Martin Stiemerling To: vijayak@india.hp.com, dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <15200000.1011177653@elgar> In-Reply-To: <001a01c19e6b$45f3cf20$2f290a0f@india.hp.com> References: <001a01c19e6b$45f3cf20$2f290a0f@india.hp.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit --On Mittwoch, Januar 16, 2002 14:23:30 +0530 Vijayabhaskar A K wrote: > Hi Martin, > > RFC for autoconf says that, in the absence of router, That's right. > the host must use DHCP. In this case, the static > route option will be very much helpful, for configuring > the routes. In the case of no on-link router, no routes are required! > > Regards > Vijay > >> -----Original Message----- >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >> Sent: Wednesday, January 16, 2002 2:05 PM >> To: vijayak@india.hp.com; dhcwg@ietf.org >> Subject: Re: [dhcwg] static route option for dhcpv6 >> >> >> Hi Vijay, >> >> why do you think a static route option is needed at all? >> For the sake of autoconfiguration it is better to keep the routing >> information in the routers and to provide only a default >> router to the host >> (which is done through the router advertisements). In the >> case that the >> router is not the best choice for a specific route, the >> router will send >> an ICMP redirect message to the corresponding host, to inform about a >> better router for this route. >> >> Regards >> Martin >> >> >> --On Dienstag, Januar 15, 2002 20:05:56 +0530 Vijayabhaskar A K >> wrote: >> >> > I have gone through the dhcpv6 22 spec. >> > I felt that, static route option (option 33 in RFC 2132) is missing. >> > which is useful for routing. Can we include this option >> > also in the spec? >> > thanks and regards >> > Vijay >> > >> > >> > >> > _______________________________________________ >> > dhcwg mailing list >> > dhcwg@ietf.org >> > https://www1.ietf.org/mailman/listinfo/dhcwg >> > >> >> >> > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 06:22:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04051; Wed, 16 Jan 2002 06:22:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26499; Wed, 16 Jan 2002 06:20:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26479 for ; Wed, 16 Jan 2002 06:20:45 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04039 for ; Wed, 16 Jan 2002 06:20:41 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id 85D1FE001F5; Wed, 16 Jan 2002 03:20:12 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id QAA06361; Wed, 16 Jan 2002 16:45:57 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Martin Stiemerling'" , Subject: RE: [dhcwg] static route option for dhcpv6 Date: Wed, 16 Jan 2002 16:51:02 +0530 Message-ID: <001c01c19e7f$e22930b0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <15200000.1011177653@elgar> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Wednesday, January 16, 2002 4:11 PM > To: vijayak@india.hp.com; dhcwg@ietf.org > Subject: RE: [dhcwg] static route option for dhcpv6 > > > > > --On Mittwoch, Januar 16, 2002 14:23:30 +0530 Vijayabhaskar A K > wrote: > > > Hi Martin, > > > > RFC for autoconf says that, in the absence of router, > > That's right. > > > the host must use DHCP. In this case, the static > > route option will be very much helpful, for configuring > > the routes. > > In the case of no on-link router, no routes are required! In the absence of an on-link IPv6 router, hosts might use configured tunnels to reach other IPv6 networks. Such routes can be sent in static-route option. > > > > > Regards > > Vijay > > > >> -----Original Message----- > >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > >> Sent: Wednesday, January 16, 2002 2:05 PM > >> To: vijayak@india.hp.com; dhcwg@ietf.org > >> Subject: Re: [dhcwg] static route option for dhcpv6 > >> > >> > >> Hi Vijay, > >> > >> why do you think a static route option is needed at all? > >> For the sake of autoconfiguration it is better to keep the routing > >> information in the routers and to provide only a default > >> router to the host > >> (which is done through the router advertisements). In the > >> case that the > >> router is not the best choice for a specific route, the > >> router will send > >> an ICMP redirect message to the corresponding host, to > inform about a > >> better router for this route. > >> > >> Regards > >> Martin > >> > >> > >> --On Dienstag, Januar 15, 2002 20:05:56 +0530 Vijayabhaskar A K > >> wrote: > >> > >> > I have gone through the dhcpv6 22 spec. > >> > I felt that, static route option (option 33 in RFC 2132) > is missing. > >> > which is useful for routing. Can we include this option > >> > also in the spec? > >> > thanks and regards > >> > Vijay > >> > > >> > > >> > > >> > _______________________________________________ > >> > dhcwg mailing list > >> > dhcwg@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > >> > >> > >> > > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 07:12:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04993; Wed, 16 Jan 2002 07:12:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28195; Wed, 16 Jan 2002 07:11:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28171 for ; Wed, 16 Jan 2002 07:11:09 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04969 for ; Wed, 16 Jan 2002 07:11:05 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0GCB4H50960; Wed, 16 Jan 2002 13:11:04 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 131F4C052; Wed, 16 Jan 2002 13:10:32 +0100 (CET) Date: Wed, 16 Jan 2002 13:25:58 +0100 From: Martin Stiemerling To: vijayak@india.hp.com, dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <8370000.1011183958@elgar> In-Reply-To: <001c01c19e7f$e22930b0$2f290a0f@india.hp.com> References: <001c01c19e7f$e22930b0$2f290a0f@india.hp.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit >> In the case of no on-link router, no routes are required! > > In the absence of an on-link IPv6 router, hosts might use configured > tunnels to reach other IPv6 networks. Such routes can be sent in > static-route option. > Yes, this might be useful, but doesn't sound directly like static routes, but more than transistioning mechanismen (IPv6 over IPv4 tunnel). There are two DSTM options in the draft, but they may not be sufficient for this purpose. Martin _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 11:11:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12565; Wed, 16 Jan 2002 11:11:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07096; Wed, 16 Jan 2002 11:08:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07068 for ; Wed, 16 Jan 2002 11:08:45 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12517 for ; Wed, 16 Jan 2002 11:08:39 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta4/8.12.2.Beta4) id g0GG8fO1016912 for dhcwg@ietf.org env-from ; Wed, 16 Jan 2002 09:08:41 -0700 (MST) Date: Wed, 16 Jan 2002 09:08:41 -0700 (MST) From: Vernon Schryver Message-Id: <200201161608.g0GG8fO1016912@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 references: <8370000.1011183958@elgar> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > From: Martin Stiemerling > To: vijayak@india.hp.com, dhcwg@ietf.org > >> In the case of no on-link router, no routes are required! > > > > In the absence of an on-link IPv6 router, hosts might use configured > > tunnels to reach other IPv6 networks. Such routes can be sent in > > static-route option. > > Yes, this might be useful, but doesn't sound directly like static routes, > but more than transistioning mechanismen (IPv6 over IPv4 tunnel). There are > two DSTM options in the draft, but they may not be sufficient for this > purpose. Doesn't IPv6 have an equivalent to the router discovery protocol? Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 11:23:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12961; Wed, 16 Jan 2002 11:23:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07593; Wed, 16 Jan 2002 11:22:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07567 for ; Wed, 16 Jan 2002 11:22:18 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12933 for ; Wed, 16 Jan 2002 11:22:14 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0GGMBH52233; Wed, 16 Jan 2002 17:22:11 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 5EC94C052; Wed, 16 Jan 2002 17:21:43 +0100 (CET) Date: Wed, 16 Jan 2002 17:37:10 +0100 From: Martin Stiemerling To: Vernon Schryver , dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <3090000.1011199030@elgar> In-Reply-To: <200201161608.g0GG8fO1016912@calcite.rhyolite.com> References: <8370000.1011183958@elgar> <200201161608.g0GG8fO1016912@calcite.rhyolite.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > > Doesn't IPv6 have an equivalent to the router discovery protocol? Router discovery via NDP. Martin > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 11:31:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13241; Wed, 16 Jan 2002 11:31:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08175; Wed, 16 Jan 2002 11:30:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08140 for ; Wed, 16 Jan 2002 11:30:36 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13182 for ; Wed, 16 Jan 2002 11:30:32 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta4/8.12.2.Beta4) id g0GGUSF9017651 for dhcwg@ietf.org env-from ; Wed, 16 Jan 2002 09:30:28 -0700 (MST) Date: Wed, 16 Jan 2002 09:30:28 -0700 (MST) From: Vernon Schryver Message-Id: <200201161630.g0GGUSF9017651@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > From: Martin Stiemerling > To: Vernon Schryver , dhcwg@ietf.org > > Doesn't IPv6 have an equivalent to the router discovery protocol? > > Router discovery via NDP. Was my point about the proposed DHCP option clear? Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 13:04:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16100; Wed, 16 Jan 2002 13:04:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12737; Wed, 16 Jan 2002 13:02:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12673 for ; Wed, 16 Jan 2002 13:02:00 -0500 (EST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16006 for ; Wed, 16 Jan 2002 13:01:42 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel6.hp.com (Postfix) with ESMTP id D4E8C600819 for ; Wed, 16 Jan 2002 13:01:09 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id XAA08447; Wed, 16 Jan 2002 23:35:21 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201161805.XAA08447@dce.india.hp.com> To: dhcwg@ietf.org Date: Wed, 16 Jan 2002 23:35:20 +0530 (IST) Cc: vijayak@dce.india.hp.com (Vijay Bhaskar A K ) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on 22 rev of the draft Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I had gone through the latest rev of DHCPv6 draft. Sorry for the delay in telling the comments. - I think we need to fix the order of occurence some options that can appear in the dhcp messages. I think, the DUID option should occur before the IA option. This makes the processing simpler. - I didn't get, why the authentication option should be the last one. I feel like it should be the first one. If the server/client is not able to validate the authentication, it can straight away discard the packet without further processing. - Section 13 says the ways for selecting addresses for assignment in IAs. Assume, the server has got a direct message from the client. The IP datagram source address is a site-local one. The message is received on the server's interface, which is configured with a global address. According to the draft, the server should assume that the client is on the link identified by the sitelocal address in datagram. Now, the problem arises, if the server is not configured for allocating site-local address for the link. Now, can the server assume, since the client has sent the direct message, it is on the same link as the server and assign it an address of global scope, with the same prefix of its received interface. I think, i have already raised the similar kind of problem previously, the answer i had got was to select address of global scope. Then, the server should not select the link based on the source address. This is an implementation problem we faced. FYI, HP has officially released DHCPv6. This implementation is based on 16th and some portion of 18th version of the draft. This software is freely available at http://software.hp.com/ You can download it and tell me your comments. - Using DUID, how the address selection is done? - The draft says that, when the client needs an additional temporary address, it can include OPTION_RTA encapsulated in OPTION_IA and get the additional one. This means, in the same IA, any number of addresses can be can be added and deleted. Will it hold for normal addresses also? I mean, for additional normal addresses, whether the client has to use already existing IA to get additional address (or) will it use a fresh IA? I remember that, the answer i got for this question 3-4 months back was that the client will use fresh IA, because, adding address to the same IA will lead complexity. Just in curiosity, i am asking, why this complexity was introduced for temporary addresses? Why can't the client can ask additional temporary addresses in a fresh IA? - Can temporary addresses and normal addresses can co-exist in same IA? If yes, then, for renewal, does the client send normal addresses alone in IA to the server? since, the renewal of temporary addresses is meaningless. - I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, the dns updates was moved to client. But, the draft says that, for temporary addresses, the server has to update the DNS. Why this feature was included in server, instead of client? - Why only temporary has to be updated in DNS? why not normal addresses? - I think for updation, we need to define, hostname/FQDN option for this. - How can the client specify the number of address it wants? Will it send IA optio with 'n' number empty of IA_ADDR option? Instead of that, can we define another option OPT_RA similar to OPT_RTA, that can be encapsulated in OPT_IA? - Section 17.1.2 says that the client collects Advertise messages until SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the client needs to retransmit the SOLICIT message? If it is so, then, the same server will reply multiple times. But the retransmission algorithm in Section 15 says that, it should retransmit the packet. - In section 17.1.2, we need to add a sentence, "When the RT reached MRT, if the one or more valid advertise message is obtained, the client should stop sending Advertise message and proceed further with collected Advertise message". Otherwise, since MRC and MRD are 0, this process will go infinetly according to algorithm specified in Section 15. This is also an implementation problem we faced. - In some place, the server should fill "server-address" with one of its address based on the link in which the packet is received. In another place, it is said that the server-address field can be filled with the address configured by the administrator. What is the standard procedure to be followed? - In Advertise, should the server assign all the addresses asked by the client? (or) only few of them? - Till what time, these OFFERED addresses are preserved for those clients to assign? - If the server has fewer addresses than the client has asked, will the server assign fewer addresses or send AddrUnavail? - The draft says that the renew message can be used for checking up the validity of the other configuration parameters. For checking the validity of them, will the client send the option codes in ORO option (or) send the parameters in their respective options? - Should release/decline of addresses be done for IA as whole? (or) Can few addresses be relased from an IA? (partial release) - Assuming the client is sending multiple IAs for renewing, the server finds that one particular IA is not found in the client bindings, will it renews the remaining IAs? (or) will it send NoBinding error? - What will the client do, for the multiple IAs sent for renew, only one IA is missing in the reply? - Can you explain the differnce between, "configuration information are not valid" and "configuration information does not match". In the first case, for Confirm message ConfNoMatch is sent and for the next one, it is sending SUCCESS. The draft says that for ConfNoMatch, the client should send renew message. If the configuration parameters are not matching, then what is the use of sending renew message? - For the cases like, "conf parameters are not valid", "conf parameters does not match" and "prefix does not match", what will the server do, for the release message? What will the server do? if (i) all, (ii) only few addresses are invalid. Will the server release the address which are valid? - Section 21.6.5.5 says that, if the client is not able to validate the authentication for the REPLY message, then it should start with the SOLICIT. I feel that this is inefficient, instead, it can try the next available server which has sent the advertise message. - In the previous versions, we have Retransmission Parameter option. Why it was removed? - Some useful options were defined in DHCPv6 extension draft. When will those options be included in this draft? I have found some typos in the draft. - In section 7.3, for reconfigure message, the client should intiate, Renew/Reply not the Request/Reply - In 19.2, it is saying that, for Inform message, all the IAs to be included. This a simple cut-paste problem. - 19.3.4 says, "The client uses the same variables and retransmission algorithm as it does with Rebind or Information....". It should be "Renew or Information..." - In 22.14, the server address field in Server Unicast Option is missing. - In 22.19, User class option message format looks messy, because of some sentences in between. Regards Vijay -- ____Vijay_Bhaskar_A_K____ ________HP_ESDI__________ ___Ph:_91_080_2051424____ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 13:14:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16334; Wed, 16 Jan 2002 13:14:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13046; Wed, 16 Jan 2002 13:12:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13022 for ; Wed, 16 Jan 2002 13:12:49 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16302 for ; Wed, 16 Jan 2002 13:12:45 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id 7FD35E00663; Wed, 16 Jan 2002 10:12:15 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id XAA20817; Wed, 16 Jan 2002 23:37:59 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , Subject: RE: [dhcwg] static route option for dhcpv6 Date: Wed, 16 Jan 2002 23:43:12 +0530 Message-ID: <000b01c19eb9$763afc00$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C19EE7.8FF33800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD87@EAMBUNT705> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C19EE7.8FF33800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: [dhcwg] static route option for dhcpv6Bernie, This option format looks ok for me. We can include it. Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Wednesday, January 16, 2002 12:21 AM To: 'vijayak@india.hp.com'; dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 How about defining the option format? I'd suggest we base this more on the Classless Static Routes option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ROUTES | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . route-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where route-data is one or more of a sequence of route table entries in the following format: 1 byte byte 16 byte destination address Where is the minimum number of bytes required to represent bits of the . A /64 prefix has the following format: 1 byte prefix (value of 64), 8-bytes of the prefix, followed by 16 bytes destination address. - Bernie Volz -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, January 15, 2002 9:36 AM To: dhcwg@ietf.org Subject: [dhcwg] static route option for dhcpv6 I have gone through the dhcpv6 22 spec. I felt that, static route option (option 33 in RFC 2132) is missing. which is useful for routing. Can we include this option also in the spec? thanks and regards Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_000_000C_01C19EE7.8FF33800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] static route option for dhcpv6
Bernie,
This option format = looks ok=20 for me. We can include=20 it.
Vijay
-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz=20 (EUD)
Sent: Wednesday, January 16, 2002 12:21 = AM
To:=20 'vijayak@india.hp.com'; dhcwg@ietf.org
Subject: RE: [dhcwg] = static=20 route option for dhcpv6

How about defining the option format?

I'd suggest we base this more on the Classless = Static Routes=20 option.

   =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
    0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6=20 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
  =20 |         =20 OPTION_ROUTES       =20 = |            = =20 option-len        | =
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
  =20 = .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 .
  =20 = .            =             &= nbsp; =20 = route-data          &nb= sp;           &nbs= p;  =20 .
  =20 = .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

Where route-data is one or more of a sequence of = route table=20 entries
in the following format:

        1 byte=20 <prefix-length> =
       =20 <n> byte <prefix address>=20
        16 byte=20 destination address

Where <n> is the minimum number of bytes = required to=20 represent
<prefix-length> bits of the = <prefix=20 address>.

A /64 prefix has the following format: 1 byte prefix = (value of=20 64),
8-bytes of the prefix, followed by 16 = bytes=20 destination address.

- Bernie Volz


-----Original Message-----
From:=20 Vijayabhaskar A K [mailto:vijayak@india.hp.com]=20
Sent: Tuesday, January 15, 2002 9:36 AM =
To: dhcwg@ietf.org
Subject: [dhcwg] = static=20 route option for dhcpv6


I have gone through the dhcpv6 22 spec. =
I felt that, static route option (option 33 in RFC 2132) is=20 missing.
which is useful for routing. Can we = include=20 this option
also in the spec? =
thanks and regards
Vijay =



_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------=_NextPart_000_000C_01C19EE7.8FF33800-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 13:16:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16481; Wed, 16 Jan 2002 13:16:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13294; Wed, 16 Jan 2002 13:16:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13270 for ; Wed, 16 Jan 2002 13:16:17 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16432 for ; Wed, 16 Jan 2002 13:16:14 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id 9DE70E00621; Wed, 16 Jan 2002 10:15:44 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id XAA21159; Wed, 16 Jan 2002 23:41:27 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Martin Stiemerling'" , Subject: RE: [dhcwg] static route option for dhcpv6 Date: Wed, 16 Jan 2002 23:46:40 +0530 Message-ID: <001001c19eb9$f2211fc0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8370000.1011183958@elgar> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit We can use this for forwarding from the network which don't have any router advertisement, but has a node in the network, attached to the another network and has ip-forwarding enabled. ~vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Martin Stiemerling > Sent: Wednesday, January 16, 2002 5:56 PM > To: vijayak@india.hp.com; dhcwg@ietf.org > Subject: RE: [dhcwg] static route option for dhcpv6 > > > >> In the case of no on-link router, no routes are required! > > > > In the absence of an on-link IPv6 router, hosts might use configured > > tunnels to reach other IPv6 networks. Such routes can be sent in > > static-route option. > > > > Yes, this might be useful, but doesn't sound directly like > static routes, > but more than transistioning mechanismen (IPv6 over IPv4 > tunnel). There are > two DSTM options in the draft, but they may not be sufficient > for this > purpose. > > Martin > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 14:10:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17890; Wed, 16 Jan 2002 14:10:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15816; Wed, 16 Jan 2002 14:09:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15736 for ; Wed, 16 Jan 2002 14:09:06 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17878 for ; Wed, 16 Jan 2002 14:09:02 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0GJ8YJ24907 for ; Wed, 16 Jan 2002 13:08:34 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0GJ8YS07600 for ; Wed, 16 Jan 2002 13:08:34 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Jan 16 13:08:33 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 13:08:33 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD98@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Vijay Bhaskar A K'" , dhcwg@ietf.org Cc: vijayak@dce.india.hp.com Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Wed, 16 Jan 2002 13:08:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19EC1.3101C1C0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19EC1.3101C1C0 Content-Type: text/plain; charset="iso-8859-1" Let me try to answer these based on my understanding/view of -22. See below. - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, January 16, 2002 1:05 PM To: dhcwg@ietf.org Cc: vijayak@dce.india.hp.com Subject: [dhcwg] Comments on 22 rev of the draft I had gone through the latest rev of DHCPv6 draft. Sorry for the delay in telling the comments. - I think we need to fix the order of occurence some options that can appear in the dhcp messages. I think, the DUID option should occur before the IA option. This makes the processing simpler. BV> I think this would be good to say that a client MUST place the DUID option in a mesage before any IA options. - I didn't get, why the authentication option should be the last one. I feel like it should be the first one. If the server/client is not able to validate the authentication, it can straight away discard the packet without further processing. BV> I too wouldn't mind having this earlier. It makes it easier to validate messages since one doesn't have to process all of the options (or at least parse to some extent all of the options) before one can authenticate the message. But, I would call this a SHOULD not a MUST. - Section 13 says the ways for selecting addresses for assignment in IAs. Assume, the server has got a direct message from the client. The IP datagram source address is a site-local one. The message is received on the server's interface, which is configured with a global address. According to the draft, the server should assume that the client is on the link identified by the sitelocal address in datagram. Now, the problem arises, if the server is not configured for allocating site-local address for the link. Now, can the server assume, since the client has sent the direct message, it is on the same link as the server and assign it an address of global scope, with the same prefix of its received interface. I think, i have already raised the similar kind of problem previously, the answer i had got was to select address of global scope. Then, the server should not select the link based on the source address. This is an implementation problem we faced. FYI, HP has officially released DHCPv6. This implementation is based on 16th and some portion of 18th version of the draft. This software is freely available at http://software.hp.com/ You can download it and tell me your comments. BV> Section 13 tells how to determine the *LINK* the client is on. Once that has been done, you assign addresses based on the prefixes that the server has configured for that *LINK*. If the source address for the DHCP message was a link local, the server knows that it can't have come from anywhere but that link (since link-local are only valid locally). But this only determines the LINK for the client; not the addresses. - Using DUID, how the address selection is done? BV> I don't understand what you are asking here. - The draft says that, when the client needs an additional temporary address, it can include OPTION_RTA encapsulated in OPTION_IA and get the additional one. This means, in the same IA, any number of addresses can be can be added and deleted. Will it hold for normal addresses also? I mean, for additional normal addresses, whether the client has to use already existing IA to get additional address (or) will it use a fresh IA? I remember that, the answer i got for this question 3-4 months back was that the client will use fresh IA, because, adding address to the same IA will lead complexity. Just in curiosity, i am asking, why this complexity was introduced for temporary addresses? Why can't the client can ask additional temporary addresses in a fresh IA? BV> We do NOT want IA explosion. Ideally, a client should be able to use the same IA forever under "normal" cases. A IA can have one or many addresses, addresses will come and go. Server policy dictates the non- temporary addresses assigned to a client. Client policy dictates the temporary address needs - hence the client must have a way to say "give me more". For example, if a client is running two applications that each want unique temporary addresses, it has to request those from the server. Later, when a third application starts, the client will need another address. - Can temporary addresses and normal addresses can co-exist in same IA? If yes, then, for renewal, does the client send normal addresses alone in IA to the server? since, the renewal of temporary addresses is meaningless. BV> YES the can both be in the SAME IA. That is the intention. - I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, the dns updates was moved to client. But, the draft says that, for temporary addresses, the server has to update the DNS. Why this feature was included in server, instead of client? BV> What we say in section 14 is: The server MAY update the DNS for a temporary address as described in section 4 of RFC3041, and MUST NOT update the DNS in any other way for a temporary address. BV> This all depends how DDNS is handled with DHCPv6 and who is doing the updates. We just wanted to be clear that if the server was doing DDNS updates for the client, is must adhere to the requirements of RFC 3041 in doing them!! - Why only temporary has to be updated in DNS? why not normal addresses? BV> See answer to previous question. DDNS updates are still TBD. Likely the DHCPv4 FQDN option will be used (changing the A processing to reflect AAAA processing and using the DUID for the client identification). - I think for updation, we need to define, hostname/FQDN option for this. BV> Yes, we will need this. - How can the client specify the number of address it wants? Will it send IA optio with 'n' number empty of IA_ADDR option? Instead of that, can we define another option OPT_RA similar to OPT_RTA, that can be encapsulated in OPT_IA? BV> The client can't specify how many non-temporary addresses it wants. This is controlled by the server. The client *CAN* use multiple IAs and if the server policy allows, that can easily be used to give the clients LOTS of addresses (one set per IA). - Section 17.1.2 says that the client collects Advertise messages until SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the client needs to retransmit the SOLICIT message? If it is so, then, the same server will reply multiple times. But the retransmission algorithm in Section 15 says that, it should retransmit the packet. BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit if it has received at least one Advertise. Retransmit Solicit only if no Advertise messages are received. - In section 17.1.2, we need to add a sentence, "When the RT reached MRT, if the one or more valid advertise message is obtained, the client should stop sending Advertise message and proceed further with collected Advertise message". Otherwise, since MRC and MRD are 0, this process will go infinetly according to algorithm specified in Section 15. This is also an implementation problem we faced. BV> Haven't studied this issue. - In some place, the server should fill "server-address" with one of its address based on the link in which the packet is received. In another place, it is said that the server-address field can be filled with the address configured by the administrator. What is the standard procedure to be followed? BV> We probably should clean up the text to be consistent. I think the answer is use configured address if so configured for that LINK, otherwise use one of the LINK interface addresses. - In Advertise, should the server assign all the addresses asked by the client? (or) only few of them? BV> It depends on the server's policies. - Till what time, these OFFERED addresses are preserved for those clients to assign? BV> My opinion is that the ADVERTISED addresses are just a possible set of addresses the client will get and may not be the exact addresses. The client must wait until the Reply to the Request before it knows which addresses it got and before it does Duplicate Address Detection. The ADVERTISE should include all of the parameters the client is likely to receive in the Reply, but they are just possible values and not the actual values. - If the server has fewer addresses than the client has asked, will the server assign fewer addresses or send AddrUnavail? BV> I would only return AddrUnavail if NO addresses are available. If you can assign some, give the client those. It can make a decisions as to whether it wants to accept them or not. - The draft says that the renew message can be used for checking up the validity of the other configuration parameters. For checking the validity of them, will the client send the option codes in ORO option (or) send the parameters in their respective options? BV> The Renew message does not need to include those options (including them in an ORO is probably a good idea so the server knows you want them). It is really the Reply that matters and the server will Reply with the current settings. The client can then apply those values. The server will (I suspect) not really check them - it just Replies with the current values. - Should release/decline of addresses be done for IA as whole? (or) Can few addresses be relased from an IA? (partial release) BV> Individual addresses can be released or declined. The client MUST include the addresses to decline/release. The server ignores any addresses that the client doesn't "own". - Assuming the client is sending multiple IAs for renewing, the server finds that one particular IA is not found in the client bindings, will it renews the remaining IAs? (or) will it send NoBinding error? BV> It can send a NoBinding status for that IA. (And renew the others.) - What will the client do, for the multiple IAs sent for renew, only one IA is missing in the reply? BV> No sure what you asking? Is this a follow up to the previous question? If the IA returns with a NoBinding status, the client may either continue to use those addresses (since it must have gotten them from someone in the past) or drop them (and the IA). - Can you explain the differnce between, "configuration information are not valid" and "configuration information does not match". In the first case, for Confirm message ConfNoMatch is sent and for the next one, it is sending SUCCESS. The draft says that for ConfNoMatch, the client should send renew message. If the configuration parameters are not matching, then what is the use of sending renew message? BV> Have to look into this one more. - For the cases like, "conf parameters are not valid", "conf parameters does not match" and "prefix does not match", what will the server do, for the release message? What will the server do? if (i) all, (ii) only few addresses are invalid. Will the server release the address which are valid? BV> Have to look into this one more. - Section 21.6.5.5 says that, if the client is not able to validate the authentication for the REPLY message, then it should start with the SOLICIT. I feel that this is inefficient, instead, it can try the next available server which has sent the advertise message. BV> Have to look into this one more. - In the previous versions, we have Retransmission Parameter option. Why it was removed? BV> There are significant security / DOS issues with allowing the server to set parameters. Also, there are issues as when these parameters are to be used (vs the defaults). If a client moves to a completely different DHCP domain, the parameters may not be valid and how does it know that? - Some useful options were defined in DHCPv6 extension draft. When will those options be included in this draft? BV> Suggest the ones you want to have included! Provide the text (if it needs to be revised). That's what Ralph (as editor) has requested in the past. I have found some typos in the draft. - In section 7.3, for reconfigure message, the client should intiate, Renew/Reply not the Request/Reply - In 19.2, it is saying that, for Inform message, all the IAs to be included. This a simple cut-paste problem. - 19.3.4 says, "The client uses the same variables and retransmission algorithm as it does with Rebind or Information....". It should be "Renew or Information..." - In 22.14, the server address field in Server Unicast Option is missing. - In 22.19, User class option message format looks messy, because of some sentences in between. Regards Vijay -- ____Vijay_Bhaskar_A_K____ ________HP_ESDI__________ ___Ph:_91_080_2051424____ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C19EC1.3101C1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Comments on 22 rev of the draft

Let me try to answer these based on my = understanding/view of -22.

See below.

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, January 16, 2002 1:05 PM
To: dhcwg@ietf.org
Cc: vijayak@dce.india.hp.com
Subject: [dhcwg] Comments on 22 rev of the = draft


I had gone through the latest rev of DHCPv6  = draft.  Sorry for the delay
in telling the comments.

- I think we need to fix the order of occurence  = some  options  that can
appear in the dhcp  messages.  I = think,  the DUID  option  should  occur
before the IA option.  This makes the = processing simpler.

BV> I think this would be good to say that a = client MUST place the DUID option in a mesage before any IA options. =

- I didn't get, why the authentication option should = be the last one.  I
feel like it should be the first one.  If = the  server/client is not able
to validate the  authentication, it can = straight away discard the packet
without further processing.

BV> I too wouldn't mind having this earlier. It = makes it easier to validate messages since one doesn't have to process = all of the options (or at least parse to some extent all of the = options) before one can authenticate the message. But, I would call = this a SHOULD not a MUST.

- Section 13 says the ways for selecting  = addresses  for  assignment  in
IAs.  Assume, the server has got a direct  = message from the client.  The
IP datagram source address is a site-local = one.  The message is received
on the server's  interface,  which is = configured with a global  address.
According to the draft, the server  = should  assume that the client is on
the link  identified  by the  = sitelocal  address in  datagram.  Now, the
problem   arises,  if  the  = server  is  not  configured  for  = allocating
site-local  address for the link.  Now, = can the server assume, since the
client has sent the direct message, it is on the = same link as the server
and assign it an address of global  = scope,  with the same  prefix of its
received  interface.  I think, i have = already raised the similar kind of
problem previously, the answer i had got was to = select address of global
scope.  Then, the server  should not = select the link based on the source
address.  This  is an  = implementation  problem  we  faced.  FYI,  HP = has
officially  released DHCPv6.  This  = implementation  is based on 16th and
some  portion of 18th  version of = the  draft.  This  software  is freely
available  at  http://software.hp.com/  You can  = download it and tell me
your comments.

BV> Section 13 tells how to determine the *LINK* = the client is on. Once
that has been done, you assign addresses based on = the prefixes that the
server has configured for that *LINK*. If the source = address for the
DHCP message was a link local, the server knows that = it can't have come
from anywhere but that link (since link-local are = only valid locally).
But this only determines the LINK for the client; = not the addresses.

- Using DUID, how the address selection is = done?

BV> I don't understand what you are asking here. =

- The draft  says that, when the client  = needs an  additional  temporary
address, it can include OPTION_RTA encapsulated in = OPTION_IA and get the
additional one.  This means, in the same IA, = any number of addresses can
be can be added and deleted.  Will it hold for = normal addresses also?  I
mean, for  additional  normal  = addresses,  whether the client has to use
already  existing IA to get additional  = address (or) will it use a fresh
IA?  I remember that, the answer i got for this = question 3-4 months back
was that the client will use fresh IA,  = because,  adding  address to the
same IA will lead  complexity.  Just in = curiosity, i am asking, why this
complexity was introduced for temporary = addresses?  Why can't the client
can ask additional temporary addresses in a fresh = IA?

BV> We do NOT want IA explosion. Ideally, a client = should be able to use
the same IA forever under "normal" cases. = A IA can have one or many
addresses, addresses will come and go. Server policy = dictates the non-
temporary addresses assigned to a client. Client = policy dictates the
temporary address needs - hence the client must have = a way to say
"give me more". For example, if a client = is running two applications that
each want unique temporary addresses, it has to = request those from the
server. Later, when a third application starts, the = client will need
another address.

- Can temporary  addresses and normal addresses = can co-exist in same IA?
If yes, then, for renewal, does the client send = normal  addresses  alone
in IA to the  server?  since,  = the  renewal of  temporary  addresses  is
meaningless.

BV> YES the can both be in the SAME IA. That is = the intention.

- I thought for decreasing the load of server, unlike = DHCPv4, in DHCPv6,
the dns  updates  was moved to  = client.  But, the draft  says  that, for
temporary addresses, the server has to update the = DNS.  Why this feature
was included in server, instead of client?

BV> What we say in section 14 is:

   The server MAY update the DNS for a = temporary address as described in
   section 4 of RFC3041, and MUST NOT = update the DNS in any other way
   for a temporary address.

BV> This all depends how DDNS is handled with = DHCPv6 and who is doing the
updates. We just wanted to be clear that if the = server was doing DDNS
updates for the client, is must adhere to the = requirements of RFC 3041
in doing them!!

-  Why  only  temporary  = has  to be  updated  in  DNS?  why  = not  normal
addresses?

BV> See answer to previous question. DDNS updates = are still TBD. Likely
the DHCPv4 FQDN option will be used (changing the A = processing to reflect
AAAA processing and using the DUID for the client = identification).

- I think for  updation,  we need to = define,  hostname/FQDN  option  for
this.

BV> Yes, we will need this.

- How can the client  specify  the number = of address  it wants?  Will it
send IA optio with 'n' number empty of IA_ADDR = option?  Instead of that,
can we define  another  option  = OPT_RA  similar to OPT_RTA,  that can be
encapsulated in OPT_IA?

BV> The client can't specify how many = non-temporary addresses it wants.
This is controlled by the server. The client *CAN* = use multiple IAs and
if the server policy allows, that can easily be used = to give the clients
LOTS of addresses (one set per IA).

- Section 17.1.2 says that the client collects  = Advertise messages until
SOL_TIMEOUT has elapsed.  Then, RT will = be  recalculated.  Now, does the
client needs to retransmit the SOLICIT  = message?  If it is so, then, the
same server will reply multiple times.  But the = retransmission algorithm
in Section 15 says that, it should retransmit the = packet.

BV> The client waits SOL_TIMEOUT but it does not = retransmit the Solicit
if it has received at least one Advertise. = Retransmit Solicit only if no
Advertise messages are received.

- In  section  17.1.2, we need to add = a  sentence,  "When the RT reached
MRT, if the one or more valid advertise  = message is obtained, the client
should stop sending Advertise message and proceed = further with collected
Advertise  message".  = Otherwise,  since MRC and MRD are 0, this  process
will go infinetly  according to algorithm = specified in Section 15.  This
is also an implementation problem we faced.

BV> Haven't studied this issue.

- In some place, the server should fill = "server-address" with one of its
address  based on the link in which the packet = is  received.  In another
place, it is said that the  = server-address  field can be filled with the
address configured by the administrator.  What = is the standard procedure
to be followed?

BV> We probably should clean up the text to be = consistent. I think the
answer is use configured address if so configured = for that LINK, otherwise
use one of the LINK interface addresses.

- In Advertise,  should the server assign all = the addresses asked by the
client?  (or) only few of them?

BV> It depends on the server's policies.

- Till what  time,  these  = OFFERED  addresses  are  preserved  for = those
clients to assign?

BV> My opinion is that the ADVERTISED addresses = are just a possible set of
addresses the client will get and may not be the = exact addresses. The client
must wait until the Reply to the Request before it = knows which addresses it
got and before it does Duplicate Address Detection. = The ADVERTISE should
include all of the parameters the client is likely = to receive in the Reply,
but they are just possible values and not the actual = values.

- If the server has fewer  addresses than the = client has asked, will the
server assign fewer addresses or send = AddrUnavail?

BV> I would only return AddrUnavail if NO = addresses are available. If you
can assign some, give the client those. It can make = a decisions as to
whether it wants to accept them or not.

- The draft says that the renew  message can be = used for checking up the
validity  of  the  other  = configuration  parameters.  For  checking  = the
validity  of them, will the client  send = the option  codes in ORO option
(or) send the parameters in their respective = options?

BV> The Renew message does not need to include = those options (including
them in an ORO is probably a good idea so the server = knows you want them).
It is really the Reply that matters and the server = will Reply with the
current settings. The client can then apply those = values. The server will
(I suspect) not really check them - it just Replies = with the current
values.

- Should release/decline of addresses be done for IA = as whole?  (or) Can
few addresses be relased from an IA? (partial = release)

BV> Individual addresses can be released or = declined. The client MUST
include the addresses to decline/release. The server = ignores any addresses
that the client doesn't "own".

- Assuming the client is sending  multiple IAs = for renewing,  the server
finds that one particular IA is not found in the = client  bindings,  will
it renews the remaining IAs? (or) will it send = NoBinding error?

BV> It can send a NoBinding status for that IA. = (And renew the others.)

- What will the client do, for the multiple IAs sent = for renew, only one
IA is missing in the reply?

BV> No sure what you asking? Is this a follow up = to the previous question?
If the IA returns with a NoBinding status, the client= may either continue
to use those addresses (since it must have gotten = them from someone in the
past) or drop them (and the IA).

- Can you explain the differnce between, = "configuration  information are
not valid" and "configuration information = does not match".  In the first
case, for Confirm  message  ConfNoMatch is = sent and for the next one, it
is  sending  SUCCESS.  The draft says = that for  ConfNoMatch,  the client
should  send renew  message.  If = the  configuration  parameters  are not
matching, then what is the use of sending renew = message?

BV> Have to look into this one more.

- For the cases like, "conf parameters are not = valid", "conf  parameters
does not match" and  "prefix  = does not match",  what will the server do,
for the release message?  What will the server = do? if (i) all, (ii) only
few  addresses  are invalid.  Will = the server  release the address which
are valid?

BV> Have to look into this one more.

- Section  21.6.5.5 says that, if the client is = not able to validate the
authentication  for the REPLY  = message,  then it should  start  with the
SOLICIT.  I feel that this is = inefficient,  instead, it can try the next
available server which has sent the advertise = message.

BV> Have to look into this one more.

- In the previous  versions, we have  = Retransmission  Parameter  option.
Why it was removed?

BV> There are significant security / DOS issues = with allowing the server
to set parameters. Also, there are issues as when = these parameters are to
be used (vs the defaults). If a client moves to a = completely different
DHCP domain, the parameters may not be valid and how = does it know that?

- Some useful options were defined in DHCPv6 = extension draft.  When will
those options be included in this draft?

BV> Suggest the ones you want to have included! = Provide the text (if it
needs to be revised). That's what Ralph (as editor) = has requested in the
past.

I have found some typos in the draft.

- In section 7.3, for  reconfigure  = message, the client should  intiate,
Renew/Reply not the Request/Reply

- In 19.2, it is  saying  that, for  = Inform  message,  all the IAs to be
included.  This a simple cut-paste = problem.

- 19.3.4 says, "The client uses the same  = variables  and  retransmission
algorithm  as it does with  Rebind  = or  Information....".  It  should be
"Renew or Information..."

- In 22.14, the server address field in Server = Unicast Option is missing.

- In 22.19, User class option  message  = format  looks messy,  because of
some sentences in between.

Regards
Vijay

--
____Vijay_Bhaskar_A_K____
________HP_ESDI__________
___Ph:_91_080_2051424____
____Telnet:_847_1424_____
___Pager:_9624_371137____


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C19EC1.3101C1C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 14:18:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18089; Wed, 16 Jan 2002 14:18:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16049; Wed, 16 Jan 2002 14:17:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16029 for ; Wed, 16 Jan 2002 14:17:16 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18049 for ; Wed, 16 Jan 2002 14:17:13 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0GJHFW13547 for ; Wed, 16 Jan 2002 13:17:15 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0GJHE429206 for ; Wed, 16 Jan 2002 13:17:14 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jan 16 13:17:13 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 13:17:13 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CD99@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Date: Wed, 16 Jan 2002 13:17:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19EC2.64E94DE0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19EC2.64E94DE0 Content-Type: text/plain; charset="iso-8859-1" After thinking about this more and after seeing the other discussion on this subject, I'm not sure exactly when or why this option would be needed. But on the other than, it technically isn't needed in IPv4 either because ICMP redirects and other routing table distribution techniques exist and DHCPv4 does have such an option (and a revised one to carry classless routes). So, we can do one of two things: 1. Include it and consider DHCPv6 as a toolbox and those people that want to use it (and those clients that want to support it) do so. For example, Solaris 8 includes the route command and it supports IPv6 routing table operations. Can anyone who has lots of experience with IPv6 deployment indicate whether there is a need to statically add routing table entries? 2. Wait until someone has a clear case of needing it and have it defined in some future document. If we do want to include it, questions to ponder: - Should any lifetimes be associated with the routes? Either one lifetime for all routes or each route? - Should this option be encapsulated within an IA? That way, it would be renewed with the IA. I myself am leaning more towards recommending we wait until a need is found. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, January 16, 2002 1:13 PM To: 'Bernie Volz (EUD)'; dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Bernie, This option format looks ok for me. We can include it. Vijay ------_=_NextPart_001_01C19EC2.64E94DE0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] static route option for dhcpv6
After thinking about this more and after seeing the other discussion on this subject, I'm not sure exactly when or why this option would be needed. But on the other than, it technically isn't needed in IPv4 either because ICMP redirects and other routing table distribution techniques exist and DHCPv4 does have such an option (and a revised one to carry classless routes).
 
So, we can do one of two things:
1. Include it and consider DHCPv6 as a toolbox and those people that want to use it (and those clients that want to support it) do so. For example, Solaris 8 includes the route command and it supports IPv6 routing table operations. Can anyone who has lots of experience with IPv6 deployment indicate whether there is a need to statically add routing table entries?
2. Wait until someone has a clear case of needing it and have it defined in some future document.
 
If we do want to include it, questions to ponder:
- Should any lifetimes be associated with the routes? Either one lifetime for all routes or each route?
- Should this option be encapsulated within an IA? That way, it would be renewed with the IA.
 
I myself am leaning more towards recommending we wait until a need is found.
 
- Bernie
 
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, January 16, 2002 1:13 PM
To: 'Bernie Volz (EUD)'; dhcwg@ietf.org
Subject: RE: [dhcwg] static route option for dhcpv6

Bernie,
This option format looks ok for me. We can include it.
Vijay
------_=_NextPart_001_01C19EC2.64E94DE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 17:47:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22772; Wed, 16 Jan 2002 17:47:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23146; Wed, 16 Jan 2002 17:43:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23120 for ; Wed, 16 Jan 2002 17:43:42 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22699 for ; Wed, 16 Jan 2002 17:43:38 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta4/8.12.2.Beta4) id g0GMhfbx029749 for dhcwg@ietf.org env-from ; Wed, 16 Jan 2002 15:43:41 -0700 (MST) Date: Wed, 16 Jan 2002 15:43:41 -0700 (MST) From: Vernon Schryver Message-Id: <200201162243.g0GMhfbx029749@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > From: "Bernie Volz (EUD)" > ... > If we do want to include it, questions to ponder: > - Should any lifetimes be associated with the routes? Either one > lifetime for all routes or each route? > - Should this option be encapsulated within an IA? That way, it > would be renewed with the IA. > > I myself am leaning more towards recommending we wait until a need is found. Perhaps another way of saying the same thing is "are you sure you want to make DHCP into a routing protocol?" In practice, the IPv4 router discovery protocol has plenty of problems that a DHCP client really doesn't need. I say this as the author of the `routed` in FreeBSD, NetBSD, and some commercial UNIX brands (yes, plural). Part of my excuse for the from-scratch rewrite of Sam Leffler's primordial code was to support IRDP, because the consensus wisdom was that IRDP was better than RIP as a router discovery protocol. A naive (on my part) result is that the commonly distributed `routed` prefers IRDP. In the simplest cases, it might well be true that IRDP is a better router discovery protocol than RIP, but it turns out that there are quite common less simple cases where RIP is clearly better. I wonder if those who want to make DHCP into an router discovery protocol have much experience with IRDP with multi-homed hosts and other minor complications. Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 16 22:58:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28878; Wed, 16 Jan 2002 22:58:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02472; Wed, 16 Jan 2002 22:57:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02453 for ; Wed, 16 Jan 2002 22:57:08 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28871 for ; Wed, 16 Jan 2002 22:57:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-438.cisco.com [10.82.241.182]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA24031; Wed, 16 Jan 2002 22:52:52 -0500 (EST) Message-Id: <4.3.2.7.2.20020116220059.00b91d18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 22:53:16 -0500 To: "'Vijay Bhaskar A K'" , "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Comments on 22 rev of the draft Cc: dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD98@EAMBUNT705> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org My thoughts on these issues... - Ralph At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) wrote: >Let me try to answer these based on my understanding/view of -22. > >See below. > >- Bernie > >-----Original Message----- >From: Vijay Bhaskar A K >[mailto:vijayak@india.hp.com] >Sent: Wednesday, January 16, 2002 1:05 PM >To: dhcwg@ietf.org >Cc: vijayak@dce.india.hp.com >Subject: [dhcwg] Comments on 22 rev of the draft > >I had gone through the latest rev of DHCPv6 draft. Sorry for the delay >in telling the comments. > >- I think we need to fix the order of occurence some options that can >appear in the dhcp messages. I think, the DUID option should occur >before the IA option. This makes the processing simpler. > >BV> I think this would be good to say that a client MUST place the DUID >option in a mesage before any IA options. RD - I'm willing to put in the text, but I don't see how it makes the processing easier. >- I didn't get, why the authentication option should be the last one. I >feel like it should be the first one. If the server/client is not able >to validate the authentication, it can straight away discard the packet >without further processing. > >BV> I too wouldn't mind having this earlier. It makes it easier to >validate messages since one doesn't have to process all of the options (or >at least parse to some extent all of the options) before one can >authenticate the message. But, I would call this a SHOULD not a MUST. RD - I'm willing to make this change. >v- Section 13 says the ways for selecting addresses for assignment in >IAs. Assume, the server has got a direct message from the client. The >IP datagram source address is a site-local one. The message is received >on the server's interface, which is configured with a global address. >According to the draft, the server should assume that the client is on >the link identified by the sitelocal address in datagram. Now, the >problem arises, if the server is not configured for allocating >site-local address for the link. Now, can the server assume, since the >client has sent the direct message, it is on the same link as the server >and assign it an address of global scope, with the same prefix of its >received interface. I think, i have already raised the similar kind of >problem previously, the answer i had got was to select address of global >scope. Then, the server should not select the link based on the source >address. This is an implementation problem we faced. FYI, HP has >officially released DHCPv6. This implementation is based on 16th and >some portion of 18th version of the draft. This software is freely >available at http://software.hp.com/ You >can download it and tell me >your comments. > >BV> Section 13 tells how to determine the *LINK* the client is on. Once >that has been done, you assign addresses based on the prefixes that the >server has configured for that *LINK*. If the source address for the >DHCP message was a link local, the server knows that it can't have come >from anywhere but that link (since link-local are only valid locally). >But this only determines the LINK for the client; not the addresses. RD - To expand on Bernie's response, the server is free to assign an address according to whatever rules it might be configure with, once the server has determined the link to which the client is attached. >- Using DUID, how the address selection is done? > >BV> I don't understand what you are asking here. RD - It's possible to encode a rule for address assignment based on DUID, which would be what is sometimes called a "reservation" in some DHCPv4 servers. >- The draft says that, when the client needs an additional temporary >address, it can include OPTION_RTA encapsulated in OPTION_IA and get the >additional one. This means, in the same IA, any number of addresses can >be can be added and deleted. Will it hold for normal addresses also? I >mean, for additional normal addresses, whether the client has to use >already existing IA to get additional address (or) will it use a fresh >IA? I remember that, the answer i got for this question 3-4 months back >was that the client will use fresh IA, because, adding address to the >same IA will lead complexity. Just in curiosity, i am asking, why this >complexity was introduced for temporary addresses? Why can't the client >can ask additional temporary addresses in a fresh IA? > >BV> We do NOT want IA explosion. Ideally, a client should be able to use >the same IA forever under "normal" cases. A IA can have one or many >addresses, addresses will come and go. Server policy dictates the non- >temporary addresses assigned to a client. Client policy dictates the >temporary address needs - hence the client must have a way to say >"give me more". For example, if a client is running two applications that >each want unique temporary addresses, it has to request those from the >server. Later, when a third application starts, the client will need >another address. RD - The complexity comes not so much from adding an address to an IA as from the semantics of how to request that the server add a new address to an IA. So, a server can replace temporary addresses in an IA as lifetimes on existing addresses expire; if a client wants more addresses, it sends a new IA. >- Can temporary addresses and normal addresses can co-exist in same IA? >If yes, then, for renewal, does the client send normal addresses alone >in IA to the server? since, the renewal of temporary addresses is >meaningless. > >BV> YES the can both be in the SAME IA. That is the intention. RD - Agreed. >- I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, >the dns updates was moved to client. But, the draft says that, for >temporary addresses, the server has to update the DNS. Why this feature >was included in server, instead of client? > >BV> What we say in section 14 is: > > The server MAY update the DNS for a temporary address as described in > section 4 of RFC3041, and MUST NOT update the DNS in any other way > for a temporary address. > >BV> This all depends how DDNS is handled with DHCPv6 and who is doing the >updates. We just wanted to be clear that if the server was doing DDNS >updates for the client, is must adhere to the requirements of RFC 3041 >in doing them!! RD - Registering a temporary address in DNS defeats the anonymity provided by that address. Clients won't want to register temporary addresses; a server may register according to the rules in RFC3041. >- Why only temporary has to be updated in DNS? why not normal >addresses? > >BV> See answer to previous question. DDNS updates are still TBD. Likely >the DHCPv4 FQDN option will be used (changing the A processing to reflect >AAAA processing and using the DUID for the client identification). RD - Agreed. >- I think for updation, we need to define, hostname/FQDN option for >this. > >BV> Yes, we will need this. RD - Agreed. >- How can the client specify the number of address it wants? Will it >send IA optio with 'n' number empty of IA_ADDR option? Instead of that, >can we define another option OPT_RA similar to OPT_RTA, that can be >encapsulated in OPT_IA? > >BV> The client can't specify how many non-temporary addresses it wants. >This is controlled by the server. The client *CAN* use multiple IAs and >if the server policy allows, that can easily be used to give the clients >LOTS of addresses (one set per IA). RD - Agreed. >- Section 17.1.2 says that the client collects Advertise messages until >SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the >client needs to retransmit the SOLICIT message? If it is so, then, the >same server will reply multiple times. But the retransmission algorithm >in Section 15 says that, it should retransmit the packet. > >BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit >if it has received at least one Advertise. Retransmit Solicit only if no >Advertise messages are received. RD - Agreed. >- In section 17.1.2, we need to add a sentence, "When the RT reached >MRT, if the one or more valid advertise message is obtained, the client >should stop sending Advertise message and proceed further with collected >Advertise message". Otherwise, since MRC and MRD are 0, this process >will go infinetly according to algorithm specified in Section 15. This >is also an implementation problem we faced. > >BV> Haven't studied this issue. RD - I don't understand the way you've explained the issue. If the client has received an Advertise message, it will terminate the retransmission process and accept the Advertise message. >- In some place, the server should fill "server-address" with one of its >address based on the link in which the packet is received. In another >place, it is said that the server-address field can be filled with the >address configured by the administrator. What is the standard procedure >to be followed? > >BV> We probably should clean up the text to be consistent. I think the >answer is use configured address if so configured for that LINK, otherwise >use one of the LINK interface addresses. RD - OK... >- In Advertise, should the server assign all the addresses asked by the >client? (or) only few of them? > >BV> It depends on the server's policies. RD - Agreed. >- Till what time, these OFFERED addresses are preserved for those >clients to assign? > >BV> My opinion is that the ADVERTISED addresses are just a possible set of >addresses the client will get and may not be the exact addresses. The client >must wait until the Reply to the Request before it knows which addresses it >got and before it does Duplicate Address Detection. The ADVERTISE should >include all of the parameters the client is likely to receive in the Reply, >but they are just possible values and not the actual values. RD - Agreed; the intention is that the Advertise message is advisory and not a firm promise of addresses to be assigned to the client. >- If the server has fewer addresses than the client has asked, will the >server assign fewer addresses or send AddrUnavail? > >BV> I would only return AddrUnavail if NO addresses are available. If you >can assign some, give the client those. It can make a decisions as to >whether it wants to accept them or not. RD - Agreed. >- The draft says that the renew message can be used for checking up the >validity of the other configuration parameters. For checking the >validity of them, will the client send the option codes in ORO option >(or) send the parameters in their respective options? > >BV> The Renew message does not need to include those options (including >them in an ORO is probably a good idea so the server knows you want them). >It is really the Reply that matters and the server will Reply with the >current settings. The client can then apply those values. The server will >(I suspect) not really check them - it just Replies with the current >values. RD - Agreed. >- Should release/decline of addresses be done for IA as whole? (or) Can >few addresses be relased from an IA? (partial release) > >BV> Individual addresses can be released or declined. The client MUST >include the addresses to decline/release. The server ignores any addresses >that the client doesn't "own". RD - Agreed. >- Assuming the client is sending multiple IAs for renewing, the server >finds that one particular IA is not found in the client bindings, will >it renews the remaining IAs? (or) will it send NoBinding error? > >BV> It can send a NoBinding status for that IA. (And renew the others.) RD - Agreed. >- What will the client do, for the multiple IAs sent for renew, only one >IA is missing in the reply? > >BV> No sure what you asking? Is this a follow up to the previous question? >If the IA returns with a NoBinding status, the client may either continue >to use those addresses (since it must have gotten them from someone in the >past) or drop them (and the IA). RD - I agree; the client can continue to use the addresses in the un-Renew-ed IA until the lifetimes for those addresses expire. >- Can you explain the differnce between, "configuration information are >not valid" and "configuration information does not match". In the first >case, for Confirm message ConfNoMatch is sent and for the next one, it >is sending SUCCESS. The draft says that for ConfNoMatch, the client >should send renew message. If the configuration parameters are not >matching, then what is the use of sending renew message? > >BV> Have to look into this one more. > >- For the cases like, "conf parameters are not valid", "conf parameters >does not match" and "prefix does not match", what will the server do, >for the release message? What will the server do? if (i) all, (ii) only >few addresses are invalid. Will the server release the address which >are valid? > >BV> Have to look into this one more. > >- Section 21.6.5.5 says that, if the client is not able to validate the >authentication for the REPLY message, then it should start with the >SOLICIT. I feel that this is inefficient, instead, it can try the next >available server which has sent the advertise message. > >BV> Have to look into this one more. > >- In the previous versions, we have Retransmission Parameter option. >Why it was removed? > >BV> There are significant security / DOS issues with allowing the server >to set parameters. Also, there are issues as when these parameters are to >be used (vs the defaults). If a client moves to a completely different >DHCP domain, the parameters may not be valid and how does it know that? RD - Agreed; in fact, when a client moves to a new link (which is the case in which the Retransmission Parameter option would be used to change the client's behavior for the new link), it's too late because the client has potentially already used the retransmission mechanism on the new link, using the parameters from the old link. >- Some useful options were defined in DHCPv6 extension draft. When will >those options be included in this draft? > >BV> Suggest the ones you want to have included! Provide the text (if it >needs to be revised). That's what Ralph (as editor) has requested in the >past. RD - Please do send requests for other options. >I have found some typos in the draft. > >- In section 7.3, for reconfigure message, the client should intiate, >Renew/Reply not the Request/Reply > >- In 19.2, it is saying that, for Inform message, all the IAs to be >included. This a simple cut-paste problem. > >- 19.3.4 says, "The client uses the same variables and retransmission >algorithm as it does with Rebind or Information....". It should be >"Renew or Information..." > >- In 22.14, the server address field in Server Unicast Option is missing. > >- In 22.19, User class option message format looks messy, because of >some sentences in between. RD - I'll fix these in the -23 rev of the draft. >Regards >Vijay > >-- >____Vijay_Bhaskar_A_K____ >________HP_ESDI__________ >___Ph:_91_080_2051424____ >____Telnet:_847_1424_____ >___Pager:_9624_371137____ > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 04:32:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10588; Thu, 17 Jan 2002 04:32:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23198; Thu, 17 Jan 2002 04:32:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23124 for ; Thu, 17 Jan 2002 04:32:02 -0500 (EST) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10583 for ; Thu, 17 Jan 2002 04:31:59 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel7.hp.com (Postfix) with ESMTP id 99BA0E00509; Thu, 17 Jan 2002 04:31:12 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA10988; Thu, 17 Jan 2002 15:05:23 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201170935.PAA10988@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: Bernie.Volz@am1.ericsson.se Date: Thu, 17 Jan 2002 15:05:22 +0530 (IST) Cc: vijayak@india.hp.com, dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD98@EAMBUNT705> from Bernie Volz at Jan "16," 2002 "01:08:33" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit See my comments inline prefixed by VB> ~Vijay > Let me try to answer these based on my understanding/view of -22. > > See below. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, January 16, 2002 1:05 PM > To: dhcwg@ietf.org > Cc: vijayak@dce.india.hp.com > Subject: [dhcwg] Comments on 22 rev of the draft > > > I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > in telling the comments. > > - I think we need to fix the order of occurence some options that can > appear in the dhcp messages. I think, the DUID option should occur > before the IA option. This makes the processing simpler. > > BV> I think this would be good to say that a client MUST place the DUID option in a mesage before any IA options. > > - I didn't get, why the authentication option should be the last one. I > feel like it should be the first one. If the server/client is not able > to validate the authentication, it can straight away discard the packet > without further processing. > > BV> I too wouldn't mind having this earlier. It makes it easier to validate messages since one doesn't have to process all of the options (or at least parse to some extent all of the options) before one can authenticate the message. But, I would call this a SHOULD not a MUST. VB> I would like to call this MUST rather than SHOULD, because, this authentication model of DHCP came only for avoiding DoS attacks. The server should not waste its time in processing these spurious packets. > > - Section 13 says the ways for selecting addresses for assignment in > IAs. Assume, the server has got a direct message from the client. The > IP datagram source address is a site-local one. The message is received > on the server's interface, which is configured with a global address. > According to the draft, the server should assume that the client is on > the link identified by the sitelocal address in datagram. Now, the > problem arises, if the server is not configured for allocating > site-local address for the link. Now, can the server assume, since the > client has sent the direct message, it is on the same link as the server > and assign it an address of global scope, with the same prefix of its > received interface. I think, i have already raised the similar kind of > problem previously, the answer i had got was to select address of global > scope. Then, the server should not select the link based on the source > address. This is an implementation problem we faced. FYI, HP has > officially released DHCPv6. This implementation is based on 16th and > some portion of 18th version of the draft. This software is freely > available at http://software.hp.com/ You can download it and tell me > your comments. > > BV> Section 13 tells how to determine the *LINK* the client is on. Once > that has been done, you assign addresses based on the prefixes that the > server has configured for that *LINK*. If the source address for the > DHCP message was a link local, the server knows that it can't have come > from anywhere but that link (since link-local are only valid locally). > But this only determines the LINK for the client; not the addresses. VB> Assume the scenario where the server and client are in same link. The configuration of server's interface and client interface is as follows. server lan0 - fe80::260:b0ff:fec1:bb6b (A link local address) server lan0:1 - 3ffe::12 (A global address) client lan0 - fe80::210:83ff:fe18:886f (A link local address) client lan0:1 - fec0::1234:27 (A site local address) server lan0 and client's lan0 are in same link. Now the client decides to get an IP address from dhcp server. So, it puts the site local address (lan0:1 addr) in the IP datagram src address field and sends the SOLICIT message. Assume, the server is configured to allocate only global address of prefix 3ffe::/64 for that link. But, according to the draft, it finds out that the message comes from fec0::1234:27/64 network, finds out it is not supposed to serve that network and hence it does not send advertise. What i feel is, since the allocation for normal addresses are dictated by server's policy, let the server dictate completely. let it not to give any preference to client's wish. In the above situation, if the server is not noticing the src address in IP datagram of the client, it can find out that the client is on the same link as the server, since it is a direct message. Thus, it can allocate allocate address of prefix 3ffe::/64. Since the SOLICIT message is sent to All DHCP Agents Address, if the server receives the client message directly, then, the client is in the same link. Thus, the decision of the link based on the IP datagram src address of the client is not at all necessary. > > - Using DUID, how the address selection is done? > > BV> I don't understand what you are asking here. > > - The draft says that, when the client needs an additional temporary > address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > additional one. This means, in the same IA, any number of addresses can > be can be added and deleted. Will it hold for normal addresses also? I > mean, for additional normal addresses, whether the client has to use > already existing IA to get additional address (or) will it use a fresh > IA? I remember that, the answer i got for this question 3-4 months back > was that the client will use fresh IA, because, adding address to the > same IA will lead complexity. Just in curiosity, i am asking, why this > complexity was introduced for temporary addresses? Why can't the client > can ask additional temporary addresses in a fresh IA? > > BV> We do NOT want IA explosion. Ideally, a client should be able to use > the same IA forever under "normal" cases. A IA can have one or many > addresses, addresses will come and go. Server policy dictates the non- > temporary addresses assigned to a client. Client policy dictates the > temporary address needs - hence the client must have a way to say > "give me more". For example, if a client is running two applications that > each want unique temporary addresses, it has to request those from the > server. Later, when a third application starts, the client will need > another address. > > - Can temporary addresses and normal addresses can co-exist in same IA? > If yes, then, for renewal, does the client send normal addresses alone > in IA to the server? since, the renewal of temporary addresses is > meaningless. > > BV> YES the can both be in the SAME IA. That is the intention. > > - I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > the dns updates was moved to client. But, the draft says that, for > temporary addresses, the server has to update the DNS. Why this feature > was included in server, instead of client? > > BV> What we say in section 14 is: > > The server MAY update the DNS for a temporary address as described in > section 4 of RFC3041, and MUST NOT update the DNS in any other way > for a temporary address. > > BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > updates. We just wanted to be clear that if the server was doing DDNS > updates for the client, is must adhere to the requirements of RFC 3041 > in doing them!! > > - Why only temporary has to be updated in DNS? why not normal > addresses? > > BV> See answer to previous question. DDNS updates are still TBD. Likely > the DHCPv4 FQDN option will be used (changing the A processing to reflect > AAAA processing and using the DUID for the client identification). > > - I think for updation, we need to define, hostname/FQDN option for > this. > > BV> Yes, we will need this. > > - How can the client specify the number of address it wants? Will it > send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > can we define another option OPT_RA similar to OPT_RTA, that can be > encapsulated in OPT_IA? > > BV> The client can't specify how many non-temporary addresses it wants. > This is controlled by the server. The client *CAN* use multiple IAs and > if the server policy allows, that can easily be used to give the clients > LOTS of addresses (one set per IA). > > - Section 17.1.2 says that the client collects Advertise messages until > SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > client needs to retransmit the SOLICIT message? If it is so, then, the > same server will reply multiple times. But the retransmission algorithm > in Section 15 says that, it should retransmit the packet. > > BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > if it has received at least one Advertise. Retransmit Solicit only if no > Advertise messages are received. VB> The Algorithm in section 15 says that, it should retransmit at the expiration on RT. The variation for SOLICIT on this algorithm in 17.1.2, does not say anything about this. So, it is better to add the statement you have stated above, in the draft also for better clarity. Otherwise, it is misleading. > > - In section 17.1.2, we need to add a sentence, "When the RT reached > MRT, if the one or more valid advertise message is obtained, the client > should stop sending Advertise message and proceed further with collected > Advertise message". Otherwise, since MRC and MRD are 0, this process > will go infinetly according to algorithm specified in Section 15. This > is also an implementation problem we faced. > > BV> Haven't studied this issue. > > - In some place, the server should fill "server-address" with one of its > address based on the link in which the packet is received. In another > place, it is said that the server-address field can be filled with the > address configured by the administrator. What is the standard procedure > to be followed? > > BV> We probably should clean up the text to be consistent. I think the > answer is use configured address if so configured for that LINK, otherwise > use one of the LINK interface addresses. > > - In Advertise, should the server assign all the addresses asked by the > client? (or) only few of them? > > BV> It depends on the server's policies. > > - Till what time, these OFFERED addresses are preserved for those > clients to assign? > > BV> My opinion is that the ADVERTISED addresses are just a possible set of > addresses the client will get and may not be the exact addresses. The client > must wait until the Reply to the Request before it knows which addresses it > got and before it does Duplicate Address Detection. The ADVERTISE should > include all of the parameters the client is likely to receive in the Reply, > but they are just possible values and not the actual values. VB> What i am asking is, in V4, there is a concept called OFFERED addresses, which will be reserved to a client. The server reserves that addresses for the some predefined time. At the expiration of the time, if the client has not sent the request, it will be allocated to some other clients. I think, if we follow the same policy, it will be better. Assume, a client sends a SOLICIT and the server replies with ADVERTISE with some addresses. Before the client sending the Request, if some other client requests for the addresses, with the current mechanism, the server will assign the addresses to new client. It may lead to server to send AddrUnavail to the first client, if the server has only limited number of addresses. It will lead to unnecessary packet transactions. > > - If the server has fewer addresses than the client has asked, will the > server assign fewer addresses or send AddrUnavail? > > BV> I would only return AddrUnavail if NO addresses are available. If you > can assign some, give the client those. It can make a decisions as to > whether it wants to accept them or not. VB> agreed. > > - The draft says that the renew message can be used for checking up the > validity of the other configuration parameters. For checking the > validity of them, will the client send the option codes in ORO option > (or) send the parameters in their respective options? > > BV> The Renew message does not need to include those options (including > them in an ORO is probably a good idea so the server knows you want them). > It is really the Reply that matters and the server will Reply with the > current settings. The client can then apply those values. The server will > (I suspect) not really check them - it just Replies with the current > values. VB> Sending the ORO option is best idea. I think we need to add the mechanism of renewal of other parameters (sending ORO option) in the draft. > > - Should release/decline of addresses be done for IA as whole? (or) Can > few addresses be relased from an IA? (partial release) > > BV> Individual addresses can be released or declined. The client MUST > include the addresses to decline/release. The server ignores any addresses > that the client doesn't "own". > > - Assuming the client is sending multiple IAs for renewing, the server > finds that one particular IA is not found in the client bindings, will > it renews the remaining IAs? (or) will it send NoBinding error? > > BV> It can send a NoBinding status for that IA. (And renew the others.) > > - What will the client do, for the multiple IAs sent for renew, only one > IA is missing in the reply? > > BV> No sure what you asking? Is this a follow up to the previous question? > If the IA returns with a NoBinding status, the client may either continue > to use those addresses (since it must have gotten them from someone in the > past) or drop them (and the IA). > > - Can you explain the differnce between, "configuration information are > not valid" and "configuration information does not match". In the first > case, for Confirm message ConfNoMatch is sent and for the next one, it > is sending SUCCESS. The draft says that for ConfNoMatch, the client > should send renew message. If the configuration parameters are not > matching, then what is the use of sending renew message? > > BV> Have to look into this one more. > > - For the cases like, "conf parameters are not valid", "conf parameters > does not match" and "prefix does not match", what will the server do, > for the release message? What will the server do? if (i) all, (ii) only > few addresses are invalid. Will the server release the address which > are valid? > > BV> Have to look into this one more. > > - Section 21.6.5.5 says that, if the client is not able to validate the > authentication for the REPLY message, then it should start with the > SOLICIT. I feel that this is inefficient, instead, it can try the next > available server which has sent the advertise message. > > BV> Have to look into this one more. > > - In the previous versions, we have Retransmission Parameter option. > Why it was removed? > > BV> There are significant security / DOS issues with allowing the server > to set parameters. Also, there are issues as when these parameters are to > be used (vs the defaults). If a client moves to a completely different > DHCP domain, the parameters may not be valid and how does it know that? VB> Agreed > > - Some useful options were defined in DHCPv6 extension draft. When will > those options be included in this draft? > > BV> Suggest the ones you want to have included! Provide the text (if it > needs to be revised). That's what Ralph (as editor) has requested in the > past. VB> I think, there are some basic configuration parameters for the host to work comfortably. We can add options for getting those configuration parameters. The options are, NIS, NIS+, NTP server addresses, SLP DA addresses and its scope list. NIS and NIS+ client domain name, Time Zone. hostname,FQDN,static route option. If you are agreeing in adding these options to base spec,i can provide the text. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 05:42:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11379; Thu, 17 Jan 2002 05:42:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25316; Thu, 17 Jan 2002 05:40:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25293 for ; Thu, 17 Jan 2002 05:40:56 -0500 (EST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11359 for ; Thu, 17 Jan 2002 05:40:52 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel13.hp.com (Postfix) with ESMTP id C1265E006B9; Thu, 17 Jan 2002 02:40:17 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id QAA11498; Thu, 17 Jan 2002 16:14:34 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201171044.QAA11498@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: rdroms@cisco.com Date: Thu, 17 Jan 2002 16:14:33 +0530 (IST) Cc: vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020116220059.00b91d18@funnel.cisco.com> from Ralph Droms at Jan "16," 2002 "10:53:16" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit See my reply inline. ~Vijay > My thoughts on these issues... > > - Ralph > > At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) wrote: > > >Let me try to answer these based on my understanding/view of -22. > > > >See below. > > > >- Bernie > > > >-----Original Message----- > >From: Vijay Bhaskar A K > >[mailto:vijayak@india.hp.com] > >Sent: Wednesday, January 16, 2002 1:05 PM > >To: dhcwg@ietf.org > >Cc: vijayak@dce.india.hp.com > >Subject: [dhcwg] Comments on 22 rev of the draft > > > >I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > >in telling the comments. > > > >- I think we need to fix the order of occurence some options that can > >appear in the dhcp messages. I think, the DUID option should occur > >before the IA option. This makes the processing simpler. > > > >BV> I think this would be good to say that a client MUST place the DUID > >option in a mesage before any IA options. > > RD - I'm willing to put in the text, but I don't see how it makes the > processing easier. VB> If DUID occurs before the IA option, then, it will be easier to locate the bindings of the client and then process the IA by IA. > > >- I didn't get, why the authentication option should be the last one. I > >feel like it should be the first one. If the server/client is not able > >to validate the authentication, it can straight away discard the packet > >without further processing. > > > >BV> I too wouldn't mind having this earlier. It makes it easier to > >validate messages since one doesn't have to process all of the options (or > >at least parse to some extent all of the options) before one can > >authenticate the message. But, I would call this a SHOULD not a MUST. > > RD - I'm willing to make this change. > > >v- Section 13 says the ways for selecting addresses for assignment in > >IAs. Assume, the server has got a direct message from the client. The > >IP datagram source address is a site-local one. The message is received > >on the server's interface, which is configured with a global address. > >According to the draft, the server should assume that the client is on > >the link identified by the sitelocal address in datagram. Now, the > >problem arises, if the server is not configured for allocating > >site-local address for the link. Now, can the server assume, since the > >client has sent the direct message, it is on the same link as the server > >and assign it an address of global scope, with the same prefix of its > >received interface. I think, i have already raised the similar kind of > >problem previously, the answer i had got was to select address of global > >scope. Then, the server should not select the link based on the source > >address. This is an implementation problem we faced. FYI, HP has > >officially released DHCPv6. This implementation is based on 16th and > >some portion of 18th version of the draft. This software is freely > >available at http://software.hp.com/ You > >can download it and tell me > >your comments. > > > >BV> Section 13 tells how to determine the *LINK* the client is on. Once > >that has been done, you assign addresses based on the prefixes that the > >server has configured for that *LINK*. If the source address for the > >DHCP message was a link local, the server knows that it can't have come > >from anywhere but that link (since link-local are only valid locally). > >But this only determines the LINK for the client; not the addresses. > > RD - To expand on Bernie's response, the server is free to assign > an address according to whatever rules it might be configure with, > once the server has determined the link to which the client is > attached. > > >- Using DUID, how the address selection is done? > > > >BV> I don't understand what you are asking here. > > RD - It's possible to encode a rule for address assignment > based on DUID, which would be what is sometimes called a > "reservation" in some DHCPv4 servers. > > >- The draft says that, when the client needs an additional temporary > >address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > >additional one. This means, in the same IA, any number of addresses can > >be can be added and deleted. Will it hold for normal addresses also? I > >mean, for additional normal addresses, whether the client has to use > >already existing IA to get additional address (or) will it use a fresh > >IA? I remember that, the answer i got for this question 3-4 months back > >was that the client will use fresh IA, because, adding address to the > >same IA will lead complexity. Just in curiosity, i am asking, why this > >complexity was introduced for temporary addresses? Why can't the client > >can ask additional temporary addresses in a fresh IA? > > > >BV> We do NOT want IA explosion. Ideally, a client should be able to use > >the same IA forever under "normal" cases. A IA can have one or many > >addresses, addresses will come and go. Server policy dictates the non- > >temporary addresses assigned to a client. Client policy dictates the > >temporary address needs - hence the client must have a way to say > >"give me more". For example, if a client is running two applications that > >each want unique temporary addresses, it has to request those from the > >server. Later, when a third application starts, the client will need > >another address. > > RD - The complexity comes not so much from adding an address > to an IA as from the semantics of how to request that the > server add a new address to an IA. So, a server can replace > temporary addresses in an IA as lifetimes on existing addresses > expire; if a client wants more addresses, it sends a new IA. VB> We can use similar option like OPT_RTA. If all the additional addresses obtained are added to same IA, then we can do renew in one short. Thus, preventing, multiple renew messages going to server. > > >- Can temporary addresses and normal addresses can co-exist in same IA? > >If yes, then, for renewal, does the client send normal addresses alone > >in IA to the server? since, the renewal of temporary addresses is > >meaningless. > > > >BV> YES the can both be in the SAME IA. That is the intention. > > RD - Agreed. > > >- I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > >the dns updates was moved to client. But, the draft says that, for > >temporary addresses, the server has to update the DNS. Why this feature > >was included in server, instead of client? > > > >BV> What we say in section 14 is: > > > > The server MAY update the DNS for a temporary address as described in > > section 4 of RFC3041, and MUST NOT update the DNS in any other way > > for a temporary address. > > > >BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > >updates. We just wanted to be clear that if the server was doing DDNS > >updates for the client, is must adhere to the requirements of RFC 3041 > >in doing them!! > > RD - Registering a temporary address in DNS defeats the anonymity > provided by that address. Clients won't want to register temporary > addresses; a server may register according to the rules > in RFC3041. > > >- Why only temporary has to be updated in DNS? why not normal > >addresses? > > > >BV> See answer to previous question. DDNS updates are still TBD. Likely > >the DHCPv4 FQDN option will be used (changing the A processing to reflect > >AAAA processing and using the DUID for the client identification). > > RD - Agreed. VB> Firstly, in most of the places, i am not able to identify whether you are agreeing my comments or bernie's. > > >- I think for updation, we need to define, hostname/FQDN option for > >this. > > > >BV> Yes, we will need this. > > RD - Agreed. > > >- How can the client specify the number of address it wants? Will it > >send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > >can we define another option OPT_RA similar to OPT_RTA, that can be > >encapsulated in OPT_IA? > > > >BV> The client can't specify how many non-temporary addresses it wants. > >This is controlled by the server. The client *CAN* use multiple IAs and > >if the server policy allows, that can easily be used to give the clients > >LOTS of addresses (one set per IA). > > RD - Agreed. > > >- Section 17.1.2 says that the client collects Advertise messages until > >SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > >client needs to retransmit the SOLICIT message? If it is so, then, the > >same server will reply multiple times. But the retransmission algorithm > >in Section 15 says that, it should retransmit the packet. > > > >BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > >if it has received at least one Advertise. Retransmit Solicit only if no > >Advertise messages are received. > > RD - Agreed. > > >- In section 17.1.2, we need to add a sentence, "When the RT reached > >MRT, if the one or more valid advertise message is obtained, the client > >should stop sending Advertise message and proceed further with collected > >Advertise message". Otherwise, since MRC and MRD are 0, this process > >will go infinetly according to algorithm specified in Section 15. This > >is also an implementation problem we faced. > > > >BV> Haven't studied this issue. > > RD - I don't understand the way you've explained the issue. If > the client has received an Advertise message, it will terminate > the retransmission process and accept the Advertise message. VB> We need to be more specific. The algorithm in Section 15 says, if MRC and MRD are 0, the transaction is infinite until the reply is obtained. The variation of this algorithm in 17.1.2 says that, the client should be waiting in collecting the advertise messages even if it has received advertise message. And, it does not say at what time, the client should stop collecting the advertise message. So, this text has to be added. > > >- In some place, the server should fill "server-address" with one of its > >address based on the link in which the packet is received. In another > >place, it is said that the server-address field can be filled with the > >address configured by the administrator. What is the standard procedure > >to be followed? > > > >BV> We probably should clean up the text to be consistent. I think the > >answer is use configured address if so configured for that LINK, otherwise > >use one of the LINK interface addresses. > > RD - OK... > > >- In Advertise, should the server assign all the addresses asked by the > >client? (or) only few of them? > > > >BV> It depends on the server's policies. > > RD - Agreed. > > >- Till what time, these OFFERED addresses are preserved for those > >clients to assign? > > > >BV> My opinion is that the ADVERTISED addresses are just a possible set of > >addresses the client will get and may not be the exact addresses. The client > >must wait until the Reply to the Request before it knows which addresses it > >got and before it does Duplicate Address Detection. The ADVERTISE should > >include all of the parameters the client is likely to receive in the Reply, > >but they are just possible values and not the actual values. > > RD - Agreed; the intention is that the Advertise message is > advisory and not a firm promise of addresses to be assigned to > the client. VB> Please refer my reply to bernie's mail... > > >- If the server has fewer addresses than the client has asked, will the > >server assign fewer addresses or send AddrUnavail? > > > >BV> I would only return AddrUnavail if NO addresses are available. If you > >can assign some, give the client those. It can make a decisions as to > >whether it wants to accept them or not. > > RD - Agreed. > > >- The draft says that the renew message can be used for checking up the > >validity of the other configuration parameters. For checking the > >validity of them, will the client send the option codes in ORO option > >(or) send the parameters in their respective options? > > > >BV> The Renew message does not need to include those options (including > >them in an ORO is probably a good idea so the server knows you want them). > >It is really the Reply that matters and the server will Reply with the > >current settings. The client can then apply those values. The server will > >(I suspect) not really check them - it just Replies with the current > >values. > > RD - Agreed. > > >- Should release/decline of addresses be done for IA as whole? (or) Can > >few addresses be relased from an IA? (partial release) > > > >BV> Individual addresses can be released or declined. The client MUST > >include the addresses to decline/release. The server ignores any addresses > >that the client doesn't "own". > > RD - Agreed. > > >- Assuming the client is sending multiple IAs for renewing, the server > >finds that one particular IA is not found in the client bindings, will > >it renews the remaining IAs? (or) will it send NoBinding error? > > > >BV> It can send a NoBinding status for that IA. (And renew the others.) > > RD - Agreed. > > >- What will the client do, for the multiple IAs sent for renew, only one > >IA is missing in the reply? > > > >BV> No sure what you asking? Is this a follow up to the previous question? > >If the IA returns with a NoBinding status, the client may either continue > >to use those addresses (since it must have gotten them from someone in the > >past) or drop them (and the IA). > > RD - I agree; the client can continue to use the addresses in the > un-Renew-ed IA until the lifetimes for those addresses expire. > > >- Can you explain the differnce between, "configuration information are > >not valid" and "configuration information does not match". In the first > >case, for Confirm message ConfNoMatch is sent and for the next one, it > >is sending SUCCESS. The draft says that for ConfNoMatch, the client > >should send renew message. If the configuration parameters are not > >matching, then what is the use of sending renew message? > > > >BV> Have to look into this one more. > > > >- For the cases like, "conf parameters are not valid", "conf parameters > >does not match" and "prefix does not match", what will the server do, > >for the release message? What will the server do? if (i) all, (ii) only > >few addresses are invalid. Will the server release the address which > >are valid? > > > >BV> Have to look into this one more. > > > >- Section 21.6.5.5 says that, if the client is not able to validate the > >authentication for the REPLY message, then it should start with the > >SOLICIT. I feel that this is inefficient, instead, it can try the next > >available server which has sent the advertise message. > > > >BV> Have to look into this one more. > > > >- In the previous versions, we have Retransmission Parameter option. > >Why it was removed? > > > >BV> There are significant security / DOS issues with allowing the server > >to set parameters. Also, there are issues as when these parameters are to > >be used (vs the defaults). If a client moves to a completely different > >DHCP domain, the parameters may not be valid and how does it know that? > > RD - Agreed; in fact, when a client moves to a new link (which is > the case in which the Retransmission Parameter option would be used > to change the client's behavior for the new link), it's too late > because the client has potentially already used the retransmission > mechanism on the new link, using the parameters from the old link. > > >- Some useful options were defined in DHCPv6 extension draft. When will > >those options be included in this draft? > > > >BV> Suggest the ones you want to have included! Provide the text (if it > >needs to be revised). That's what Ralph (as editor) has requested in the > >past. > > RD - Please do send requests for other options. > > >I have found some typos in the draft. > > > >- In section 7.3, for reconfigure message, the client should intiate, > >Renew/Reply not the Request/Reply > > > >- In 19.2, it is saying that, for Inform message, all the IAs to be > >included. This a simple cut-paste problem. > > > >- 19.3.4 says, "The client uses the same variables and retransmission > >algorithm as it does with Rebind or Information....". It should be > >"Renew or Information..." > > > >- In 22.14, the server address field in Server Unicast Option is missing. > > > >- In 22.19, User class option message format looks messy, because of > >some sentences in between. > > RD - I'll fix these in the -23 rev of the draft. > > > >Regards > >Vijay > > > >-- > >____Vijay_Bhaskar_A_K____ > >________HP_ESDI__________ > >___Ph:_91_080_2051424____ > >____Telnet:_847_1424_____ > >___Pager:_9624_371137____ > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 06:20:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11777; Thu, 17 Jan 2002 06:20:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26587; Thu, 17 Jan 2002 06:19:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26567 for ; Thu, 17 Jan 2002 06:19:13 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11766 for ; Thu, 17 Jan 2002 06:19:08 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0HBJ4H57092; Thu, 17 Jan 2002 12:19:04 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 87C48C052; Thu, 17 Jan 2002 12:18:35 +0100 (CET) Date: Thu, 17 Jan 2002 12:18:35 +0100 From: Martin Stiemerling To: "Bernie Volz (EUD)" , "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <10620000.1011266315@elgar> In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD99@EAMBUNT705> References: <66F66129A77AD411B76200508B65AC69B4CD99@EAMBUNT705> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, comments are inline. --On Mittwoch, Januar 16, 2002 13:17:09 -0600 "Bernie Volz (EUD)" wrote: > > After thinking about this more and after seeing the other discussion on > this subject, I'm not sure exactly when or why this option would be I'm not sure, too. But I would be happy if Vijay could make a small picture with the scenario his thinking of to get a clear view. > needed. But on the other than, it technically isn't needed in IPv4 either > because ICMP redirects and other routing table distribution techniques > exist and DHCPv4 does have such an option (and a revised one to carry > classless routes). > So, we can do one of two things: > 1. Include it and consider DHCPv6 as a toolbox and those people that want > to use it (and those clients that want to support it) do so. For example, > Solaris 8 includes the route command and it supports IPv6 routing table > operations. Can anyone who has lots of experience with IPv6 deployment > indicate whether there is a need to statically add routing table entries? I do the IPv6 deployment for a complete site, and I haven't encounter such a situation where a host needs a static route. But I'm willing to learn. > 2. Wait until someone has a clear case of needing it and have it defined > in some future document. I prefer this way. Martin > If we do want to include it, questions to ponder: > - Should any lifetimes be associated with the routes? Either one lifetime > for all routes or each route? - Should this option be encapsulated > within an IA? That way, it would be renewed with the IA. > I myself am leaning more towards recommending we wait until a need is > found. > - Bernie > > > > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, January 16, 2002 1:13 PM > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org > Subject: RE: [dhcwg] static route option for dhcpv6 > > > > Bernie, > This option format looks ok for me. We can include it. > Vijay > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 07:51:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13561; Thu, 17 Jan 2002 07:51:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29851; Thu, 17 Jan 2002 07:45:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29825 for ; Thu, 17 Jan 2002 07:44:59 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13435 for ; Thu, 17 Jan 2002 07:44:56 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel11.hp.com (Postfix) with ESMTP id 81124E0069E; Thu, 17 Jan 2002 04:44:15 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id SAA12123; Thu, 17 Jan 2002 18:18:32 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201171248.SAA12123@dce.india.hp.com> Subject: Re: [dhcwg] static route option for dhcpv6 To: Bernie.Volz@am1.ericsson.se Date: Thu, 17 Jan 2002 18:18:31 +0530 (IST) Cc: vijayak@india.hp.com, dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD99@EAMBUNT705> from Bernie Volz at Jan "16," 2002 "01:17:09" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Please see my comments inline. ~Vijay. > After thinking about this more and after seeing the other discussion on this subject, I'm not sure exactly when or why this option would be needed. But on the other than, it technically isn't needed in IPv4 either because ICMP redirects and other routing table distribution techniques exist and DHCPv4 does have such an option (and a revised one to carry classless routes). > > So, we can do one of two things: > 1. Include it and consider DHCPv6 as a toolbox and those people that want to use it (and those clients that want to support it) do so. For example, Solaris 8 includes the route command and it supports IPv6 routing table operations. Can anyone who has lots of experience with IPv6 deployment indicate whether there is a need to statically add routing table entries? > 2. Wait until someone has a clear case of needing it and have it defined in some future document. Assume the following scenaria. - There are 2 networks A and B. - There is a node n connected to both the network, and it has enabled ipv6-forwarding and not sending router advertisements. Now, a node in network A gets an address from the DHCPv6 server and now it wants to communicate with a node in network B. In the current scenario, the route has to be manually configured, then only, it will be able to contact the node in network B. With static route option, we can autoconfigure it. This will be more helpful in getting minimal configuration for smaller networks, which don't have any router advertisements and for the networks which have not completely deployed routing mechanisms. It will be useful in the getting the configured tunnels also. > > If we do want to include it, questions to ponder: > - Should any lifetimes be associated with the routes? Either one lifetime for all routes or each route? > - Should this option be encapsulated within an IA? That way, it would be renewed with the IA. I think, we can treat this as another configuration parameter. We don't need to mix up with IA. If there are multiple IAs with same prefix, then this static route is common for all these IAs. Whenever there is a change in the static route, we can use reconfiguration mechanism to update it. > > I myself am leaning more towards recommending we wait until a need is found. > > - Bernie > > > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, January 16, 2002 1:13 PM > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org > Subject: RE: [dhcwg] static route option for dhcpv6 > > > Bernie, > This option format looks ok for me. We can include it. > Vijay > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 12:31:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27531; Thu, 17 Jan 2002 12:31:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14251; Thu, 17 Jan 2002 12:30:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14216 for ; Thu, 17 Jan 2002 12:30:27 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27507 for ; Thu, 17 Jan 2002 12:30:21 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02378; Thu, 17 Jan 2002 12:29:00 -0500 Date: Thu, 17 Jan 2002 12:29:00 -0500 (EST) From: Jim Bound To: Vijay Bhaskar A K Cc: Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org Subject: Re: [dhcwg] static route option for dhcpv6 In-Reply-To: <200201171248.SAA12123@dce.india.hp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org We need the static route option for the dentist office scenarios of IPv6 where there are two lans and no routers or as VJ pointed out ipv6forwardin g is turned on and not doing RAs. We also want it for configured tunnels and its different than DSTM. We should also keep it simple as a config parameter. I see no pain here and it is needed. Its a simple option to add and necessary for early IPv6 deployment as VJ pointed out in first mails. regards, /jim On Thu, 17 Jan 2002, Vijay Bhaskar A K wrote: > Please see my comments inline. > > ~Vijay. > > > After thinking about this more and after seeing the other discussion on this subject, I'm not sure exactly when or why this option would be needed. But on the other than, it technically isn't needed in IPv4 either because ICMP redirects and other routing table distribution techniques exist and DHCPv4 does have such an option (and a revised one to carry classless routes). > > > > So, we can do one of two things: > > 1. Include it and consider DHCPv6 as a toolbox and those people that want to use it (and those clients that want to support it) do so. For example, Solaris 8 includes the route command and it supports IPv6 routing table operations. Can anyone who has lots of experience with IPv6 deployment indicate whether there is a need to statically add routing table entries? > > 2. Wait until someone has a clear case of needing it and have it defined in some future document. > > Assume the following scenaria. > - There are 2 networks A and B. > - There is a node n connected to both the network, and it has enabled > ipv6-forwarding and not sending router advertisements. > > Now, a node in network A gets an address from the DHCPv6 server and now > it wants to communicate with a node in network B. In the current > scenario, the route has to be manually configured, then only, it will be > able to contact the node in network B. With static route option, we can > autoconfigure it. This will be more helpful in getting minimal > configuration for smaller networks, which don't have any router > advertisements and for the networks which have not completely deployed > routing mechanisms. > > It will be useful in the getting the configured tunnels also. > > > > > If we do want to include it, questions to ponder: > > - Should any lifetimes be associated with the routes? Either one lifetime for all routes or each route? > > - Should this option be encapsulated within an IA? That way, it would be renewed with the IA. > > I think, we can treat this as another configuration parameter. We don't > need to mix up with IA. If there are multiple IAs with same prefix, > then this static route is common for all these IAs. Whenever there is a > change in the static route, we can use reconfiguration mechanism to > update it. > > > > > I myself am leaning more towards recommending we wait until a need is found. > > > > - Bernie > > > > > > -----Original Message----- > > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Wednesday, January 16, 2002 1:13 PM > > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org > > Subject: RE: [dhcwg] static route option for dhcpv6 > > > > > > Bernie, > > This option format looks ok for me. We can include it. > > Vijay > > > > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ______Ph:_2051424________ > ____Telnet:_847_1424_____ > ___Pager:_9624_371137____ > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 22:18:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19482; Thu, 17 Jan 2002 22:18:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07298; Thu, 17 Jan 2002 22:17:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17543 for ; Thu, 17 Jan 2002 13:41:02 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29698 for ; Thu, 17 Jan 2002 13:40:59 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0HIf0W09558 for ; Thu, 17 Jan 2002 12:41:01 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0HIf0g16346 for ; Thu, 17 Jan 2002 12:41:00 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jan 17 12:41:00 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 12:40:59 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDB6@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Vijay Bhaskar A K'" , rdroms@cisco.com Cc: "Bernie Volz (EUD)" , dhcwg@ietf.org Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Thu, 17 Jan 2002 12:40:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F86.80381E40" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19F86.80381E40 Content-Type: text/plain; charset="iso-8859-1" Vijay: Again, my comments are BV3. (I still have to look into the few that I previously flagged as such.) - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Thursday, January 17, 2002 5:45 AM To: rdroms@cisco.com Cc: vijayak@india.hp.com; Bernie.Volz@am1.ericsson.se; dhcwg@ietf.org Subject: Re: [dhcwg] Comments on 22 rev of the draft See my reply inline. ~Vijay > My thoughts on these issues... > > - Ralph > > At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) wrote: > > >Let me try to answer these based on my understanding/view of -22. > > > >See below. > > > >- Bernie > > > >-----Original Message----- > >From: Vijay Bhaskar A K > >[mailto:vijayak@india.hp.com] > >Sent: Wednesday, January 16, 2002 1:05 PM > >To: dhcwg@ietf.org > >Cc: vijayak@dce.india.hp.com > >Subject: [dhcwg] Comments on 22 rev of the draft > > > >I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > >in telling the comments. > > > >- I think we need to fix the order of occurence some options that can > >appear in the dhcp messages. I think, the DUID option should occur > >before the IA option. This makes the processing simpler. > > > >BV> I think this would be good to say that a client MUST place the DUID > >option in a mesage before any IA options. > > RD - I'm willing to put in the text, but I don't see how it makes the > processing easier. VB> If DUID occurs before the IA option, then, it will be easier to locate the bindings of the client and then process the IA by IA. > > >- I didn't get, why the authentication option should be the last one. I > >feel like it should be the first one. If the server/client is not able > >to validate the authentication, it can straight away discard the packet > >without further processing. > > > >BV> I too wouldn't mind having this earlier. It makes it easier to > >validate messages since one doesn't have to process all of the options (or > >at least parse to some extent all of the options) before one can > >authenticate the message. But, I would call this a SHOULD not a MUST. > > RD - I'm willing to make this change. > > >v- Section 13 says the ways for selecting addresses for assignment in > >IAs. Assume, the server has got a direct message from the client. The > >IP datagram source address is a site-local one. The message is received > >on the server's interface, which is configured with a global address. > >According to the draft, the server should assume that the client is on > >the link identified by the sitelocal address in datagram. Now, the > >problem arises, if the server is not configured for allocating > >site-local address for the link. Now, can the server assume, since the > >client has sent the direct message, it is on the same link as the server > >and assign it an address of global scope, with the same prefix of its > >received interface. I think, i have already raised the similar kind of > >problem previously, the answer i had got was to select address of global > >scope. Then, the server should not select the link based on the source > >address. This is an implementation problem we faced. FYI, HP has > >officially released DHCPv6. This implementation is based on 16th and > >some portion of 18th version of the draft. This software is freely > >available at http://software.hp.com/ You > >can download it and tell me > >your comments. > > > >BV> Section 13 tells how to determine the *LINK* the client is on. Once > >that has been done, you assign addresses based on the prefixes that the > >server has configured for that *LINK*. If the source address for the > >DHCP message was a link local, the server knows that it can't have come > >from anywhere but that link (since link-local are only valid locally). > >But this only determines the LINK for the client; not the addresses. > > RD - To expand on Bernie's response, the server is free to assign > an address according to whatever rules it might be configure with, > once the server has determined the link to which the client is > attached. > > >- Using DUID, how the address selection is done? > > > >BV> I don't understand what you are asking here. > > RD - It's possible to encode a rule for address assignment > based on DUID, which would be what is sometimes called a > "reservation" in some DHCPv4 servers. > > >- The draft says that, when the client needs an additional temporary > >address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > >additional one. This means, in the same IA, any number of addresses can > >be can be added and deleted. Will it hold for normal addresses also? I > >mean, for additional normal addresses, whether the client has to use > >already existing IA to get additional address (or) will it use a fresh > >IA? I remember that, the answer i got for this question 3-4 months back > >was that the client will use fresh IA, because, adding address to the > >same IA will lead complexity. Just in curiosity, i am asking, why this > >complexity was introduced for temporary addresses? Why can't the client > >can ask additional temporary addresses in a fresh IA? > > > >BV> We do NOT want IA explosion. Ideally, a client should be able to use > >the same IA forever under "normal" cases. A IA can have one or many > >addresses, addresses will come and go. Server policy dictates the non- > >temporary addresses assigned to a client. Client policy dictates the > >temporary address needs - hence the client must have a way to say > >"give me more". For example, if a client is running two applications that > >each want unique temporary addresses, it has to request those from the > >server. Later, when a third application starts, the client will need > >another address. > > RD - The complexity comes not so much from adding an address > to an IA as from the semantics of how to request that the > server add a new address to an IA. So, a server can replace > temporary addresses in an IA as lifetimes on existing addresses > expire; if a client wants more addresses, it sends a new IA. VB> We can use similar option like OPT_RTA. If all the additional addresses obtained are added to same IA, then we can do renew in one short. Thus, preventing, multiple renew messages going to server. > > >- Can temporary addresses and normal addresses can co-exist in same IA? > >If yes, then, for renewal, does the client send normal addresses alone > >in IA to the server? since, the renewal of temporary addresses is > >meaningless. > > > >BV> YES the can both be in the SAME IA. That is the intention. > > RD - Agreed. > > >- I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > >the dns updates was moved to client. But, the draft says that, for > >temporary addresses, the server has to update the DNS. Why this feature > >was included in server, instead of client? > > > >BV> What we say in section 14 is: > > > > The server MAY update the DNS for a temporary address as described in > > section 4 of RFC3041, and MUST NOT update the DNS in any other way > > for a temporary address. > > > >BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > >updates. We just wanted to be clear that if the server was doing DDNS > >updates for the client, is must adhere to the requirements of RFC 3041 > >in doing them!! > > RD - Registering a temporary address in DNS defeats the anonymity > provided by that address. Clients won't want to register temporary > addresses; a server may register according to the rules > in RFC3041. > > >- Why only temporary has to be updated in DNS? why not normal > >addresses? > > > >BV> See answer to previous question. DDNS updates are still TBD. Likely > >the DHCPv4 FQDN option will be used (changing the A processing to reflect > >AAAA processing and using the DUID for the client identification). > > RD - Agreed. VB> Firstly, in most of the places, i am not able to identify whether you are agreeing my comments or bernie's. BV3> I believe Ralph is agreeing with me (at least I hope so!). > > >- I think for updation, we need to define, hostname/FQDN option for > >this. > > > >BV> Yes, we will need this. > > RD - Agreed. > > >- How can the client specify the number of address it wants? Will it > >send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > >can we define another option OPT_RA similar to OPT_RTA, that can be > >encapsulated in OPT_IA? > > > >BV> The client can't specify how many non-temporary addresses it wants. > >This is controlled by the server. The client *CAN* use multiple IAs and > >if the server policy allows, that can easily be used to give the clients > >LOTS of addresses (one set per IA). > > RD - Agreed. > > >- Section 17.1.2 says that the client collects Advertise messages until > >SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > >client needs to retransmit the SOLICIT message? If it is so, then, the > >same server will reply multiple times. But the retransmission algorithm > >in Section 15 says that, it should retransmit the packet. > > > >BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > >if it has received at least one Advertise. Retransmit Solicit only if no > >Advertise messages are received. > > RD - Agreed. > > >- In section 17.1.2, we need to add a sentence, "When the RT reached > >MRT, if the one or more valid advertise message is obtained, the client > >should stop sending Advertise message and proceed further with collected > >Advertise message". Otherwise, since MRC and MRD are 0, this process > >will go infinetly according to algorithm specified in Section 15. This > >is also an implementation problem we faced. > > > >BV> Haven't studied this issue. > > RD - I don't understand the way you've explained the issue. If > the client has received an Advertise message, it will terminate > the retransmission process and accept the Advertise message. VB> We need to be more specific. The algorithm in Section 15 says, if MRC and MRD are 0, the transaction is infinite until the reply is obtained. The variation of this algorithm in 17.1.2 says that, the client should be waiting in collecting the advertise messages even if it has received advertise message. And, it does not say at what time, the client should stop collecting the advertise message. So, this text has to be added. BV3> Ah, but a reply (lower case r) - Advertise in this case - HAS been received, so retransmission would stop. It is just that the client doesn't continue processing immediately by Requesting ... instead it waits for more Advertises to arrive. > > >- In some place, the server should fill "server-address" with one of its > >address based on the link in which the packet is received. In another > >place, it is said that the server-address field can be filled with the > >address configured by the administrator. What is the standard procedure > >to be followed? > > > >BV> We probably should clean up the text to be consistent. I think the > >answer is use configured address if so configured for that LINK, otherwise > >use one of the LINK interface addresses. > > RD - OK... > > >- In Advertise, should the server assign all the addresses asked by the > >client? (or) only few of them? > > > >BV> It depends on the server's policies. > > RD - Agreed. > > >- Till what time, these OFFERED addresses are preserved for those > >clients to assign? > > > >BV> My opinion is that the ADVERTISED addresses are just a possible set of > >addresses the client will get and may not be the exact addresses. The client > >must wait until the Reply to the Request before it knows which addresses it > >got and before it does Duplicate Address Detection. The ADVERTISE should > >include all of the parameters the client is likely to receive in the Reply, > >but they are just possible values and not the actual values. > > RD - Agreed; the intention is that the Advertise message is > advisory and not a firm promise of addresses to be assigned to > the client. VB> Please refer my reply to bernie's mail... > > >- If the server has fewer addresses than the client has asked, will the > >server assign fewer addresses or send AddrUnavail? > > > >BV> I would only return AddrUnavail if NO addresses are available. If you > >can assign some, give the client those. It can make a decisions as to > >whether it wants to accept them or not. > > RD - Agreed. > > >- The draft says that the renew message can be used for checking up the > >validity of the other configuration parameters. For checking the > >validity of them, will the client send the option codes in ORO option > >(or) send the parameters in their respective options? > > > >BV> The Renew message does not need to include those options (including > >them in an ORO is probably a good idea so the server knows you want them). > >It is really the Reply that matters and the server will Reply with the > >current settings. The client can then apply those values. The server will > >(I suspect) not really check them - it just Replies with the current > >values. > > RD - Agreed. > > >- Should release/decline of addresses be done for IA as whole? (or) Can > >few addresses be relased from an IA? (partial release) > > > >BV> Individual addresses can be released or declined. The client MUST > >include the addresses to decline/release. The server ignores any addresses > >that the client doesn't "own". > > RD - Agreed. > > >- Assuming the client is sending multiple IAs for renewing, the server > >finds that one particular IA is not found in the client bindings, will > >it renews the remaining IAs? (or) will it send NoBinding error? > > > >BV> It can send a NoBinding status for that IA. (And renew the others.) > > RD - Agreed. > > >- What will the client do, for the multiple IAs sent for renew, only one > >IA is missing in the reply? > > > >BV> No sure what you asking? Is this a follow up to the previous question? > >If the IA returns with a NoBinding status, the client may either continue > >to use those addresses (since it must have gotten them from someone in the > >past) or drop them (and the IA). > > RD - I agree; the client can continue to use the addresses in the > un-Renew-ed IA until the lifetimes for those addresses expire. > > >- Can you explain the differnce between, "configuration information are > >not valid" and "configuration information does not match". In the first > >case, for Confirm message ConfNoMatch is sent and for the next one, it > >is sending SUCCESS. The draft says that for ConfNoMatch, the client > >should send renew message. If the configuration parameters are not > >matching, then what is the use of sending renew message? > > > >BV> Have to look into this one more. > > > >- For the cases like, "conf parameters are not valid", "conf parameters > >does not match" and "prefix does not match", what will the server do, > >for the release message? What will the server do? if (i) all, (ii) only > >few addresses are invalid. Will the server release the address which > >are valid? > > > >BV> Have to look into this one more. > > > >- Section 21.6.5.5 says that, if the client is not able to validate the > >authentication for the REPLY message, then it should start with the > >SOLICIT. I feel that this is inefficient, instead, it can try the next > >available server which has sent the advertise message. > > > >BV> Have to look into this one more. > > > >- In the previous versions, we have Retransmission Parameter option. > >Why it was removed? > > > >BV> There are significant security / DOS issues with allowing the server > >to set parameters. Also, there are issues as when these parameters are to > >be used (vs the defaults). If a client moves to a completely different > >DHCP domain, the parameters may not be valid and how does it know that? > > RD - Agreed; in fact, when a client moves to a new link (which is > the case in which the Retransmission Parameter option would be used > to change the client's behavior for the new link), it's too late > because the client has potentially already used the retransmission > mechanism on the new link, using the parameters from the old link. > > >- Some useful options were defined in DHCPv6 extension draft. When will > >those options be included in this draft? > > > >BV> Suggest the ones you want to have included! Provide the text (if it > >needs to be revised). That's what Ralph (as editor) has requested in the > >past. > > RD - Please do send requests for other options. > > >I have found some typos in the draft. > > > >- In section 7.3, for reconfigure message, the client should intiate, > >Renew/Reply not the Request/Reply > > > >- In 19.2, it is saying that, for Inform message, all the IAs to be > >included. This a simple cut-paste problem. > > > >- 19.3.4 says, "The client uses the same variables and retransmission > >algorithm as it does with Rebind or Information....". It should be > >"Renew or Information..." > > > >- In 22.14, the server address field in Server Unicast Option is missing. > > > >- In 22.19, User class option message format looks messy, because of > >some sentences in between. > > RD - I'll fix these in the -23 rev of the draft. > > > >Regards > >Vijay > > > >-- > >____Vijay_Bhaskar_A_K____ > >________HP_ESDI__________ > >___Ph:_91_080_2051424____ > >____Telnet:_847_1424_____ > >___Pager:_9624_371137____ > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C19F86.80381E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Comments on 22 rev of the draft

Vijay:

Again, my comments are BV3. (I still have to look = into the few that I previously flagged as such.)

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, January 17, 2002 5:45 AM
To: rdroms@cisco.com
Cc: vijayak@india.hp.com; = Bernie.Volz@am1.ericsson.se; dhcwg@ietf.org
Subject: Re: [dhcwg] Comments on 22 rev of the = draft


See my reply inline.

~Vijay

> My thoughts on these issues...
>
> - Ralph
>
> At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) = wrote:
>
> >Let me try to answer these based on my = understanding/view of -22.
> >
> >See below.
> >
> >- Bernie
> >
> >-----Original Message-----
> >From: Vijay Bhaskar A K
> >[<mailto:vijayak@india.hp.com>= mailto:vijayak@india.hp.com]
> >Sent: Wednesday, January 16, 2002 1:05 = PM
> >To: dhcwg@ietf.org
> >Cc: vijayak@dce.india.hp.com
> >Subject: [dhcwg] Comments on 22 rev of the = draft
> >
> >I had gone through the latest rev of = DHCPv6  draft.  Sorry for the delay
> >in telling the comments.
> >
> >- I think we need to fix the order of = occurence  some  options  that can
> >appear in the dhcp  messages.  I = think,  the DUID  option  should  occur
> >before the IA option.  This makes the = processing simpler.
> >
> >BV> I think this would be good to say = that a client MUST place the DUID
> >option in a mesage before any IA = options.
>
> RD - I'm willing to put in the text, but I = don't see how it makes the
> processing easier.

VB> If DUID  occurs  before  the = IA  option,  then, it will be easier to
locate the bindings of the client and then process = the IA by IA.

>
> >- I didn't get, why the authentication = option should be the last one.  I
> >feel like it should be the first one.  = If the  server/client is not able
> >to validate the  authentication, it = can straight away discard the packet
> >without further processing.
> >
> >BV> I too wouldn't mind having this = earlier. It makes it easier to
> >validate messages since one doesn't have to = process all of the options (or
> >at least parse to some extent all of the = options) before one can
> >authenticate the message. But, I would call = this a SHOULD not a MUST.
>
> RD - I'm willing to make this change.
>
> >v- Section 13 says the ways for = selecting  addresses  for  assignment  in
> >IAs.  Assume, the server has got a = direct  message from the client.  The
> >IP datagram source address is a site-local = one.  The message is received
> >on the server's  interface,  = which is configured with a global  address.
> >According to the draft, the server  = should  assume that the client is on
> >the link  identified  by = the  sitelocal  address in  datagram.  Now, = the
> >problem   arises,  if  = the  server  is  not  configured  for  = allocating
> >site-local  address for the = link.  Now, can the server assume, since the
> >client has sent the direct message, it is = on the same link as the server
> >and assign it an address of global  = scope,  with the same  prefix of its
> >received  interface.  I think, i = have already raised the similar kind of
> >problem previously, the answer i had got = was to select address of global
> >scope.  Then, the server  should = not select the link based on the source
> >address.  This  is an  = implementation  problem  we  faced.  FYI,  HP = has
> >officially  released DHCPv6.  = This  implementation  is based on 16th and
> >some  portion of 18th  version of = the  draft.  This  software  is freely
> >available  at  <http://software.hp.com/>http://software.hp.com/  You
> >can  download it and tell me
> >your comments.
> >
> >BV> Section 13 tells how to determine = the *LINK* the client is on. Once
> >that has been done, you assign addresses = based on the prefixes that the
> >server has configured for that *LINK*. If = the source address for the
> >DHCP message was a link local, the server = knows that it can't have come
> >from anywhere but that link (since = link-local are only valid locally).
> >But this only determines the LINK for the = client; not the addresses.
>
> RD - To expand on Bernie's response, the server = is free to assign
> an address according to whatever rules it might = be configure with,
> once the server has determined the link to = which the client is
> attached.
>
> >- Using DUID, how the address selection is = done?
> >
> >BV> I don't understand what you are = asking here.
>
> RD - It's possible to encode a rule for address = assignment
> based on DUID, which would be what is sometimes = called a
> "reservation" in some DHCPv4 = servers.
>
> >- The draft  says that, when the = client  needs an  additional  temporary
> >address, it can include OPTION_RTA = encapsulated in OPTION_IA and get the
> >additional one.  This means, in the = same IA, any number of addresses can
> >be can be added and deleted.  Will it = hold for normal addresses also?  I
> >mean, for  additional  = normal  addresses,  whether the client has to use
> >already  existing IA to get = additional  address (or) will it use a fresh
> >IA?  I remember that, the answer i got = for this question 3-4 months back
> >was that the client will use fresh = IA,  because,  adding  address to the
> >same IA will lead  complexity.  = Just in curiosity, i am asking, why this
> >complexity was introduced for temporary = addresses?  Why can't the client
> >can ask additional temporary addresses in a = fresh IA?
> >
> >BV> We do NOT want IA explosion. = Ideally, a client should be able to use
> >the same IA forever under = "normal" cases. A IA can have one or many
> >addresses, addresses will come and go. = Server policy dictates the non-
> >temporary addresses assigned to a client. = Client policy dictates the
> >temporary address needs - hence the client = must have a way to say
> >"give me more". For example, if a = client is running two applications that
> >each want unique temporary addresses, it = has to request those from the
> >server. Later, when a third application = starts, the client will need
> >another address.
>
> RD - The complexity comes not so much from = adding an address
> to an IA as from the semantics of how to = request that the
> server add a new address to an IA.  So, a = server can replace
> temporary addresses in an IA as lifetimes on = existing addresses
> expire; if a client wants more addresses, it = sends a new IA.

VB> We can  use  similar  = option  like  OPT_RTA.  If all the  = additional
addresses  obtained  are  added to = same  IA, then we can do renew in one
short.  Thus, preventing, multiple renew = messages going to server.

>
> >- Can temporary  addresses and normal = addresses can co-exist in same IA?
> >If yes, then, for renewal, does the client = send normal  addresses  alone
> >in IA to the  server?  = since,  the  renewal of  temporary  addresses  = is
> >meaningless.
> >
> >BV> YES the can both be in the SAME IA. = That is the intention.
>
> RD - Agreed.
>
> >- I thought for decreasing the load of = server, unlike DHCPv4, in DHCPv6,
> >the dns  updates  was moved = to  client.  But, the draft  says  that, for
> >temporary addresses, the server has to = update the DNS.  Why this feature
> >was included in server, instead of = client?
> >
> >BV> What we say in section 14 is:
> >
> >    The server MAY update = the DNS for a temporary address as described in
> >    section 4 of RFC3041, = and MUST NOT update the DNS in any other way
> >    for a temporary = address.
> >
> >BV> This all depends how DDNS is handled = with DHCPv6 and who is doing the
> >updates. We just wanted to be clear that if = the server was doing DDNS
> >updates for the client, is must adhere to = the requirements of RFC 3041
> >in doing them!!
>
> RD - Registering a temporary address in DNS = defeats the anonymity
> provided by that address.  Clients won't = want to register temporary
> addresses; a server may register according to = the rules
> in RFC3041.
>
> >-  Why  only  = temporary  has  to be  updated  in  DNS?  = why  not  normal
> >addresses?
> >
> >BV> See answer to previous question. = DDNS updates are still TBD. Likely
> >the DHCPv4 FQDN option will be used = (changing the A processing to reflect
> >AAAA processing and using the DUID for the = client identification).
>
> RD - Agreed.

VB> Firstly, in most of the places, i am not able = to identify whether you are agreeing my comments or bernie's.

BV3> I believe Ralph is agreeing with me (at least = I hope so!).

>
> >- I think for  updation,  we need = to define,  hostname/FQDN  option  for
> >this.
> >
> >BV> Yes, we will need this.
>
> RD - Agreed.
>
> >- How can the client  specify  = the number of address  it wants?  Will it
> >send IA optio with 'n' number empty of = IA_ADDR option?  Instead of that,
> >can we define  another  = option  OPT_RA  similar to OPT_RTA,  that can be
> >encapsulated in OPT_IA?
> >
> >BV> The client can't specify how many = non-temporary addresses it wants.
> >This is controlled by the server. The = client *CAN* use multiple IAs and
> >if the server policy allows, that can = easily be used to give the clients
> >LOTS of addresses (one set per IA).
>
> RD - Agreed.
>
> >- Section 17.1.2 says that the client = collects  Advertise messages until
> >SOL_TIMEOUT has elapsed.  Then, RT = will be  recalculated.  Now, does the
> >client needs to retransmit the = SOLICIT  message?  If it is so, then, the
> >same server will reply multiple = times.  But the retransmission algorithm
> >in Section 15 says that, it should = retransmit the packet.
> >
> >BV> The client waits SOL_TIMEOUT but it = does not retransmit the Solicit
> >if it has received at least one Advertise. = Retransmit Solicit only if no
> >Advertise messages are received.
>
> RD - Agreed.
>
> >- In  section  17.1.2, we need to = add a  sentence,  "When the RT reached
> >MRT, if the one or more valid = advertise  message is obtained, the client
> >should stop sending Advertise message and = proceed further with collected
> >Advertise  message".  = Otherwise,  since MRC and MRD are 0, this  process
> >will go infinetly  according to = algorithm specified in Section 15.  This
> >is also an implementation problem we = faced.
> >
> >BV> Haven't studied this issue.
>
> RD - I don't understand the way you've = explained the issue.  If
> the client has received an Advertise message, = it will terminate
> the retransmission process and accept the = Advertise message.

VB> We need to be more  specific.  = The  algorithm in Section 15 says, if
MRC and MRD are 0, the  transaction  = is  infinite  until  the  reply  is
obtained.  The  variation  of = this  algorithm  in 17.1.2  says that, the
client should be waiting in collecting the advertise = messages even if it
has received advertise  message.  And, it = does not say at what time, the
client should stop collecting the advertise  = message.  So, this text has
to be added.

BV3> Ah, but a reply (lower case r) - Advertise in = this case - HAS been
received, so retransmission would stop. It is just = that the client doesn't
continue processing immediately by Requesting ... = instead it waits for
more Advertises to arrive.

>
> >- In some place, the server should fill = "server-address" with one of its
> >address  based on the link in which = the packet is  received.  In another
> >place, it is said that the  = server-address  field can be filled with the
> >address configured by the = administrator.  What is the standard procedure
> >to be followed?
> >
> >BV> We probably should clean up the text = to be consistent. I think the
> >answer is use configured address if so = configured for that LINK, otherwise
> >use one of the LINK interface = addresses.
>
> RD - OK...
>
> >- In Advertise,  should the server = assign all the addresses asked by the
> >client?  (or) only few of them?
> >
> >BV> It depends on the server's = policies.
>
> RD - Agreed.
>
> >- Till what  time,  these  = OFFERED  addresses  are  preserved  for = those
> >clients to assign?
> >
> >BV> My opinion is that the ADVERTISED = addresses are just a possible set of
> >addresses the client will get and may not = be the exact addresses. The client
> >must wait until the Reply to the Request = before it knows which addresses it
> >got and before it does Duplicate Address = Detection. The ADVERTISE should
> >include all of the parameters the client is = likely to receive in the Reply,
> >but they are just possible values and not = the actual values.
>
> RD - Agreed; the intention is that the = Advertise message is
> advisory and not a firm promise of addresses to = be assigned to
> the client.

VB> Please refer my reply to bernie's = mail...

>
> >- If the server has fewer  addresses = than the client has asked, will the
> >server assign fewer addresses or send = AddrUnavail?
> >
> >BV> I would only return AddrUnavail if = NO addresses are available. If you
> >can assign some, give the client those. It = can make a decisions as to
> >whether it wants to accept them or = not.
>
> RD - Agreed.
>
> >- The draft says that the renew  = message can be used for checking up the
> >validity  of  the  = other  configuration  parameters.  For  = checking  the
> >validity  of them, will the = client  send the option  codes in ORO option
> >(or) send the parameters in their = respective options?
> >
> >BV> The Renew message does not need to = include those options (including
> >them in an ORO is probably a good idea so = the server knows you want them).
> >It is really the Reply that matters and the = server will Reply with the
> >current settings. The client can then apply = those values. The server will
> >(I suspect) not really check them - it just = Replies with the current
> >values.
>
> RD - Agreed.
>
> >- Should release/decline of addresses be = done for IA as whole?  (or) Can
> >few addresses be relased from an IA? = (partial release)
> >
> >BV> Individual addresses can be released = or declined. The client MUST
> >include the addresses to decline/release. = The server ignores any addresses
> >that the client doesn't = "own".
>
> RD - Agreed.
>
> >- Assuming the client is sending  = multiple IAs for renewing,  the server
> >finds that one particular IA is not found = in the client  bindings,  will
> >it renews the remaining IAs? (or) will it = send NoBinding error?
> >
> >BV> It can send a NoBinding status for = that IA. (And renew the others.)
>
> RD - Agreed.
>
> >- What will the client do, for the multiple = IAs sent for renew, only one
> >IA is missing in the reply?
> >
> >BV> No sure what you asking? Is this a = follow up to the previous question?
> >If the IA returns with a NoBinding status, = the client may either continue
> >to use those addresses (since it must have = gotten them from someone in the
> >past) or drop them (and the IA).
>
> RD - I agree; the client can continue to use = the addresses in the
> un-Renew-ed IA until the lifetimes for those = addresses expire.
>
> >- Can you explain the differnce between, = "configuration  information are
> >not valid" and "configuration = information does not match".  In the first
> >case, for Confirm  message  = ConfNoMatch is sent and for the next one, it
> >is  sending  SUCCESS.  The = draft says that for  ConfNoMatch,  the client
> >should  send renew  = message.  If the  configuration  parameters  are = not
> >matching, then what is the use of sending = renew message?
> >
> >BV> Have to look into this one = more.
> >
> >- For the cases like, "conf parameters = are not valid", "conf  parameters
> >does not match" and  = "prefix  does not match",  what will the server = do,
> >for the release message?  What will = the server do? if (i) all, (ii) only
> >few  addresses  are = invalid.  Will the server  release the address which
> >are valid?
> >
> >BV> Have to look into this one = more.
> >
> >- Section  21.6.5.5 says that, if the = client is not able to validate the
> >authentication  for the REPLY  = message,  then it should  start  with the
> >SOLICIT.  I feel that this is = inefficient,  instead, it can try the next
> >available server which has sent the = advertise message.
> >
> >BV> Have to look into this one = more.
> >
> >- In the previous  versions, we = have  Retransmission  Parameter  option.
> >Why it was removed?
> >
> >BV> There are significant security / DOS = issues with allowing the server
> >to set parameters. Also, there are issues = as when these parameters are to
> >be used (vs the defaults). If a client = moves to a completely different
> >DHCP domain, the parameters may not be = valid and how does it know that?
>
> RD - Agreed; in fact, when a client moves to a = new link (which is
> the case in which the Retransmission Parameter = option would be used
> to change the client's behavior for the new = link), it's too late
> because the client has potentially already used = the retransmission
> mechanism on the new link, using the parameters = from the old link.
>
> >- Some useful options were defined in = DHCPv6 extension draft.  When will
> >those options be included in this = draft?
> >
> >BV> Suggest the ones you want to have = included! Provide the text (if it
> >needs to be revised). That's what Ralph (as = editor) has requested in the
> >past.
>
> RD - Please do send requests for other = options.
>
> >I have found some typos in the = draft.
> >
> >- In section 7.3, for  = reconfigure  message, the client should  intiate,
> >Renew/Reply not the Request/Reply
> >
> >- In 19.2, it is  saying  that, = for  Inform  message,  all the IAs to be
> >included.  This a simple cut-paste = problem.
> >
> >- 19.3.4 says, "The client uses the = same  variables  and  retransmission
> >algorithm  as it does with  = Rebind  or  Information....".  It  should = be
> >"Renew or Information..."
> >
> >- In 22.14, the server address field in = Server Unicast Option is missing.
> >
> >- In 22.19, User class option  = message  format  looks messy,  because of
> >some sentences in between.
>
> RD - I'll fix these in the -23 rev of the = draft.
>
>
> >Regards
> >Vijay
> >
> >--
> >____Vijay_Bhaskar_A_K____
> >________HP_ESDI__________
> >___Ph:_91_080_2051424____
> >____<Telnet:_847_1424_____>Telnet:_847_1424_____
> >___Pager:_9624_371137____
> >
> = >_______________________________________________
> >dhcwg mailing list
> >dhcwg@ietf.org
> ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg =
> >
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>


--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
______Ph:_2051424________
____Telnet:_847_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C19F86.80381E40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 17 22:18:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19484; Thu, 17 Jan 2002 22:18:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07328; Thu, 17 Jan 2002 22:17:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16231 for ; Thu, 17 Jan 2002 13:10:55 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28755 for ; Thu, 17 Jan 2002 13:10:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0HIAfW14032 for ; Thu, 17 Jan 2002 12:10:41 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0HIAfu28100 for ; Thu, 17 Jan 2002 12:10:41 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jan 17 12:10:40 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 12:10:40 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDB4@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Vijay Bhaskar A K'" , "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Thu, 17 Jan 2002 12:10:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F82.4514F210" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C19F82.4514F210 Content-Type: text/plain; charset="iso-8859-1" Vijay, see BV2> comments. - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Thursday, January 17, 2002 4:35 AM To: Bernie.Volz@am1.ericsson.se Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: [dhcwg] Comments on 22 rev of the draft See my comments inline prefixed by VB> ~Vijay > Let me try to answer these based on my understanding/view of -22. > > See below. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, January 16, 2002 1:05 PM > To: dhcwg@ietf.org > Cc: vijayak@dce.india.hp.com > Subject: [dhcwg] Comments on 22 rev of the draft > > > I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > in telling the comments. > > - I think we need to fix the order of occurence some options that can > appear in the dhcp messages. I think, the DUID option should occur > before the IA option. This makes the processing simpler. > > BV> I think this would be good to say that a client MUST place the DUID option in a mesage before any IA options. > > - I didn't get, why the authentication option should be the last one. I > feel like it should be the first one. If the server/client is not able > to validate the authentication, it can straight away discard the packet > without further processing. > > BV> I too wouldn't mind having this earlier. It makes it easier to validate messages since one doesn't have to process all of the options (or at least parse to some extent all of the options) before one can authenticate the message. But, I would call this a SHOULD not a MUST. VB> I would like to call this MUST rather than SHOULD, because, this authentication model of DHCP came only for avoiding DoS attacks. The server should not waste its time in processing these spurious packets. > > - Section 13 says the ways for selecting addresses for assignment in > IAs. Assume, the server has got a direct message from the client. The > IP datagram source address is a site-local one. The message is received > on the server's interface, which is configured with a global address. > According to the draft, the server should assume that the client is on > the link identified by the sitelocal address in datagram. Now, the > problem arises, if the server is not configured for allocating > site-local address for the link. Now, can the server assume, since the > client has sent the direct message, it is on the same link as the server > and assign it an address of global scope, with the same prefix of its > received interface. I think, i have already raised the similar kind of > problem previously, the answer i had got was to select address of global > scope. Then, the server should not select the link based on the source > address. This is an implementation problem we faced. FYI, HP has > officially released DHCPv6. This implementation is based on 16th and > some portion of 18th version of the draft. This software is freely > available at http://software.hp.com/ You can download it and tell me > your comments. > > BV> Section 13 tells how to determine the *LINK* the client is on. Once > that has been done, you assign addresses based on the prefixes that the > server has configured for that *LINK*. If the source address for the > DHCP message was a link local, the server knows that it can't have come > from anywhere but that link (since link-local are only valid locally). > But this only determines the LINK for the client; not the addresses. VB> Assume the scenario where the server and client are in same link. The configuration of server's interface and client interface is as follows. server lan0 - fe80::260:b0ff:fec1:bb6b (A link local address) server lan0:1 - 3ffe::12 (A global address) client lan0 - fe80::210:83ff:fe18:886f (A link local address) client lan0:1 - fec0::1234:27 (A site local address) server lan0 and client's lan0 are in same link. Now the client decides to get an IP address from dhcp server. So, it puts the site local address (lan0:1 addr) in the IP datagram src address field and sends the SOLICIT message. Assume, the server is configured to allocate only global address of prefix 3ffe::/64 for that link. But, according to the draft, it finds out that the message comes from fec0::1234:27/64 network, finds out it is not supposed to serve that network and hence it does not send advertise. What i feel is, since the allocation for normal addresses are dictated by server's policy, let the server dictate completely. let it not to give any preference to client's wish. In the above situation, if the server is not noticing the src address in IP datagram of the client, it can find out that the client is on the same link as the server, since it is a direct message. Thus, it can allocate allocate address of prefix 3ffe::/64. Since the SOLICIT message is sent to All DHCP Agents Address, if the server receives the client message directly, then, the client is in the same link. Thus, the decision of the link based on the IP datagram src address of the client is not at all necessary. BV2> Again, all the server does is use the address to determine the LINK. So, the server needs to know about the site local prefix being active on the link but that's all. If the server fails to find the prefix for the address, it can either drop the request or it could simply assume it must have come from the LINKs associated with the interface the packet was received on. So, it is happy. Note that the client really should be using the link local address UNLESS it is unicasting to a server (in which case it must use an address of sufficient scope valid for the server to send replies). The All DHCP Agents address is link scoped, so the source address only needs to be linked scoped as well. So, I don't see any issues here. Or am I failing to understand your concern? > > - Using DUID, how the address selection is done? > > BV> I don't understand what you are asking here. > > - The draft says that, when the client needs an additional temporary > address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > additional one. This means, in the same IA, any number of addresses can > be can be added and deleted. Will it hold for normal addresses also? I > mean, for additional normal addresses, whether the client has to use > already existing IA to get additional address (or) will it use a fresh > IA? I remember that, the answer i got for this question 3-4 months back > was that the client will use fresh IA, because, adding address to the > same IA will lead complexity. Just in curiosity, i am asking, why this > complexity was introduced for temporary addresses? Why can't the client > can ask additional temporary addresses in a fresh IA? > > BV> We do NOT want IA explosion. Ideally, a client should be able to use > the same IA forever under "normal" cases. A IA can have one or many > addresses, addresses will come and go. Server policy dictates the non- > temporary addresses assigned to a client. Client policy dictates the > temporary address needs - hence the client must have a way to say > "give me more". For example, if a client is running two applications that > each want unique temporary addresses, it has to request those from the > server. Later, when a third application starts, the client will need > another address. > > - Can temporary addresses and normal addresses can co-exist in same IA? > If yes, then, for renewal, does the client send normal addresses alone > in IA to the server? since, the renewal of temporary addresses is > meaningless. > > BV> YES the can both be in the SAME IA. That is the intention. > > - I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > the dns updates was moved to client. But, the draft says that, for > temporary addresses, the server has to update the DNS. Why this feature > was included in server, instead of client? > > BV> What we say in section 14 is: > > The server MAY update the DNS for a temporary address as described in > section 4 of RFC3041, and MUST NOT update the DNS in any other way > for a temporary address. > > BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > updates. We just wanted to be clear that if the server was doing DDNS > updates for the client, is must adhere to the requirements of RFC 3041 > in doing them!! > > - Why only temporary has to be updated in DNS? why not normal > addresses? > > BV> See answer to previous question. DDNS updates are still TBD. Likely > the DHCPv4 FQDN option will be used (changing the A processing to reflect > AAAA processing and using the DUID for the client identification). > > - I think for updation, we need to define, hostname/FQDN option for > this. > > BV> Yes, we will need this. > > - How can the client specify the number of address it wants? Will it > send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > can we define another option OPT_RA similar to OPT_RTA, that can be > encapsulated in OPT_IA? > > BV> The client can't specify how many non-temporary addresses it wants. > This is controlled by the server. The client *CAN* use multiple IAs and > if the server policy allows, that can easily be used to give the clients > LOTS of addresses (one set per IA). > > - Section 17.1.2 says that the client collects Advertise messages until > SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > client needs to retransmit the SOLICIT message? If it is so, then, the > same server will reply multiple times. But the retransmission algorithm > in Section 15 says that, it should retransmit the packet. > > BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > if it has received at least one Advertise. Retransmit Solicit only if no > Advertise messages are received. VB> The Algorithm in section 15 says that, it should retransmit at the expiration on RT. The variation for SOLICIT on this algorithm in 17.1.2, does not say anything about this. So, it is better to add the statement you have stated above, in the draft also for better clarity. Otherwise, it is misleading. BV2> I will review the text again to see if this was not clear. > > - In section 17.1.2, we need to add a sentence, "When the RT reached > MRT, if the one or more valid advertise message is obtained, the client > should stop sending Advertise message and proceed further with collected > Advertise message". Otherwise, since MRC and MRD are 0, this process > will go infinetly according to algorithm specified in Section 15. This > is also an implementation problem we faced. > > BV> Haven't studied this issue. > > - In some place, the server should fill "server-address" with one of its > address based on the link in which the packet is received. In another > place, it is said that the server-address field can be filled with the > address configured by the administrator. What is the standard procedure > to be followed? > > BV> We probably should clean up the text to be consistent. I think the > answer is use configured address if so configured for that LINK, otherwise > use one of the LINK interface addresses. > > - In Advertise, should the server assign all the addresses asked by the > client? (or) only few of them? > > BV> It depends on the server's policies. > > - Till what time, these OFFERED addresses are preserved for those > clients to assign? > > BV> My opinion is that the ADVERTISED addresses are just a possible set of > addresses the client will get and may not be the exact addresses. The client > must wait until the Reply to the Request before it knows which addresses it > got and before it does Duplicate Address Detection. The ADVERTISE should > include all of the parameters the client is likely to receive in the Reply, > but they are just possible values and not the actual values. VB> What i am asking is, in V4, there is a concept called OFFERED addresses, which will be reserved to a client. The server reserves that addresses for the some predefined time. At the expiration of the time, if the client has not sent the request, it will be allocated to some other clients. I think, if we follow the same policy, it will be better. Assume, a client sends a SOLICIT and the server replies with ADVERTISE with some addresses. Before the client sending the Request, if some other client requests for the addresses, with the current mechanism, the server will assign the addresses to new client. It may lead to server to send AddrUnavail to the first client, if the server has only limited number of addresses. It will lead to unnecessary packet transactions. BV2> I don't agree. It is much better if the server can just send something out and not have to do anything to remember it. With IPv6, what's the likelyhood that an address won't be available - we have 2^64 addresses on each prefix! BV2> What I view the ADVERTISE message to be is for the server to say I am willing to give you this stuff [assuming it is avaiable] but that I haven't given you the EXACT stuff you will get (since that happens in the Reply to the Request). BV2> BUT please note that this really is up to each SERVER to do what it wants. A SERVER can chose to ADVERTISE real stuff and "reserve" it for some period of time (and that is a SERVER implementation issue). In my server, I might chose that time to be 0 seconds. In your server, you can set it to 1 hour. The client can't do anything with ADVERTISEd information other than make a decision based on which ADVERTISE it wants to accept (assuming it gets multiple). In any case, the information from the Reply is what it must install. So, this is purely a server implementation issue. > > - If the server has fewer addresses than the client has asked, will the > server assign fewer addresses or send AddrUnavail? > > BV> I would only return AddrUnavail if NO addresses are available. If you > can assign some, give the client those. It can make a decisions as to > whether it wants to accept them or not. VB> agreed. > > - The draft says that the renew message can be used for checking up the > validity of the other configuration parameters. For checking the > validity of them, will the client send the option codes in ORO option > (or) send the parameters in their respective options? > > BV> The Renew message does not need to include those options (including > them in an ORO is probably a good idea so the server knows you want them). > It is really the Reply that matters and the server will Reply with the > current settings. The client can then apply those values. The server will > (I suspect) not really check them - it just Replies with the current > values. VB> Sending the ORO option is best idea. I think we need to add the mechanism of renewal of other parameters (sending ORO option) in the draft. BV2> Yeah, but that is already clear. See 22.6 (ORO option) text. And also Appendix B. > > - Should release/decline of addresses be done for IA as whole? (or) Can > few addresses be relased from an IA? (partial release) > > BV> Individual addresses can be released or declined. The client MUST > include the addresses to decline/release. The server ignores any addresses > that the client doesn't "own". > > - Assuming the client is sending multiple IAs for renewing, the server > finds that one particular IA is not found in the client bindings, will > it renews the remaining IAs? (or) will it send NoBinding error? > > BV> It can send a NoBinding status for that IA. (And renew the others.) > > - What will the client do, for the multiple IAs sent for renew, only one > IA is missing in the reply? > > BV> No sure what you asking? Is this a follow up to the previous question? > If the IA returns with a NoBinding status, the client may either continue > to use those addresses (since it must have gotten them from someone in the > past) or drop them (and the IA). > > - Can you explain the differnce between, "configuration information are > not valid" and "configuration information does not match". In the first > case, for Confirm message ConfNoMatch is sent and for the next one, it > is sending SUCCESS. The draft says that for ConfNoMatch, the client > should send renew message. If the configuration parameters are not > matching, then what is the use of sending renew message? > > BV> Have to look into this one more. > > - For the cases like, "conf parameters are not valid", "conf parameters > does not match" and "prefix does not match", what will the server do, > for the release message? What will the server do? if (i) all, (ii) only > few addresses are invalid. Will the server release the address which > are valid? > > BV> Have to look into this one more. > > - Section 21.6.5.5 says that, if the client is not able to validate the > authentication for the REPLY message, then it should start with the > SOLICIT. I feel that this is inefficient, instead, it can try the next > available server which has sent the advertise message. > > BV> Have to look into this one more. > > - In the previous versions, we have Retransmission Parameter option. > Why it was removed? > > BV> There are significant security / DOS issues with allowing the server > to set parameters. Also, there are issues as when these parameters are to > be used (vs the defaults). If a client moves to a completely different > DHCP domain, the parameters may not be valid and how does it know that? VB> Agreed > > - Some useful options were defined in DHCPv6 extension draft. When will > those options be included in this draft? > > BV> Suggest the ones you want to have included! Provide the text (if it > needs to be revised). That's what Ralph (as editor) has requested in the > past. VB> I think, there are some basic configuration parameters for the host to work comfortably. We can add options for getting those configuration parameters. The options are, NIS, NIS+, NTP server addresses, SLP DA addresses and its scope list. NIS and NIS+ client domain name, Time Zone. hostname,FQDN,static route option. If you are agreeing in adding these options to base spec,i can provide the text. BV2> Supply proposed text (similar to the existing Options sections). If you don't supply it, the options won't be in the base spec. If you do, it will just depend on what the WG thinks of them. I don't really see any significant reason not to include the ones you propose. I think the major issue is to have a clear reason for the option and to assure it is well define/specified. One tactic that has been used is to wait to define the options until a clear need is found (since then a clearer specification of the option can be written!). ------_=_NextPart_001_01C19F82.4514F210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Comments on 22 rev of the draft

Vijay, see BV2> comments.

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, January 17, 2002 4:35 AM
To: Bernie.Volz@am1.ericsson.se
Cc: vijayak@india.hp.com; dhcwg@ietf.org
Subject: Re: [dhcwg] Comments on 22 rev of the = draft


See my comments inline prefixed by VB>

~Vijay

> Let me try to answer these based on my = understanding/view of -22.
>
> See below.
>
> - Bernie
>
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
> Sent: Wednesday, January 16, 2002 1:05 = PM
> To: dhcwg@ietf.org
> Cc: vijayak@dce.india.hp.com
> Subject: [dhcwg] Comments on 22 rev of the = draft
>
>
> I had gone through the latest rev of = DHCPv6  draft.  Sorry for the delay
> in telling the comments.
>
> - I think we need to fix the order of = occurence  some  options  that can
> appear in the dhcp  messages.  I = think,  the DUID  option  should  occur
> before the IA option.  This makes the = processing simpler.
>
> BV> I think this would be good to say that a = client MUST place the DUID option in a mesage before any IA options. =
>
> - I didn't get, why the authentication option = should be the last one.  I
> feel like it should be the first one.  If = the  server/client is not able
> to validate the  authentication, it can = straight away discard the packet
> without further processing.
>
> BV> I too wouldn't mind having this earlier. = It makes it easier to validate messages since one doesn't have to = process all of the options (or at least parse to some extent all of the = options) before one can authenticate the message. But, I would call = this a SHOULD not a MUST.

VB> I would like to call this MUST rather  = than  SHOULD,  because,  this
authentication  model of DHCP came only for = avoiding  DoS  attacks.  The
server should not waste its time in processing these = spurious packets.

>
> - Section 13 says the ways for selecting  = addresses  for  assignment  in
> IAs.  Assume, the server has got a = direct  message from the client.  The
> IP datagram source address is a site-local one.&= nbsp; The message is received
> on the server's  interface,  which is = configured with a global  address.
> According to the draft, the server  = should  assume that the client is on
> the link  identified  by the  = sitelocal  address in  datagram.  Now, the
> problem   arises,  if  = the  server  is  not  configured  for  = allocating
> site-local  address for the link.  = Now, can the server assume, since the
> client has sent the direct message, it is on = the same link as the server
> and assign it an address of global  = scope,  with the same  prefix of its
> received  interface.  I think, i have = already raised the similar kind of
> problem previously, the answer i had got was to = select address of global
> scope.  Then, the server  should not = select the link based on the source
> address.  This  is an  = implementation  problem  we  faced.  FYI,  HP = has
> officially  released DHCPv6.  = This  implementation  is based on 16th and
> some  portion of 18th  version of = the  draft.  This  software  is freely
> available  at  http://software.hp.com/  You can  = download it and tell me
> your comments.
>
> BV> Section 13 tells how to determine the = *LINK* the client is on. Once
> that has been done, you assign addresses based = on the prefixes that the
> server has configured for that *LINK*. If the = source address for the
> DHCP message was a link local, the server knows = that it can't have come
> from anywhere but that link (since link-local = are only valid locally).
> But this only determines the LINK for the = client; not the addresses.

VB> Assume the  scenario  where the = server and client  are in same link.
The  configuration  of server's  = interface  and client  interface  is as
follows.

server lan0   -  = fe80::260:b0ff:fec1:bb6b (A link local address)
server lan0:1 -  3ffe::12 (A global = address)
client lan0   -  = fe80::210:83ff:fe18:886f (A link local address)
client lan0:1 -  fec0::1234:27 (A site local = address)

server lan0 and client's lan0 are in same link.  = Now the client  decides
to get an IP  address  from  = dhcp  server.  So, it puts  the site  local
address (lan0:1 addr) in the IP datagram src address = field and sends the
SOLICIT  message.  Assume, the server = is  configured  to  allocate  only
global address of prefix 3ffe::/64 for that = link.  But, according to the
draft,  it finds  out  that  = the  message  comes  from  fec0::1234:27/64
network, finds out it is not supposed to serve that = network and hence it
does not send  advertise.  What i = feel  is,  since  the  allocation  for
normal addresses are dictated by server's policy, = let the server dictate
completely.  let it not to give any preference = to client's wish.  In the
above  situation,  if the server is = not  noticing  the src address in IP
datagram  of the  client, it can find out = that the client is on the same
link as the server, since it is a direct = message.  Thus, it can allocate
allocate address of prefix 3ffe::/64.  Since = the SOLICIT message is sent
to All DHCP Agents  Address, if the = server  receives the client  message
directly,  then, the client is in the same = link.  Thus, the  decision of
the link based on the IP  datagram  = src  address of the client is not at
all necessary.

BV2> Again, all the server does is use the address = to determine the LINK.
So, the server needs to know about the site local = prefix being active on
the link but that's all. If the server fails to find = the prefix for the
address, it can either drop the request or it could = simply assume it must
have come from the LINKs associated with the = interface the packet was
received on. So, it is happy.

Note that the client really should be using the link = local address UNLESS
it is unicasting to a server (in which case it must = use an address of
sufficient scope valid for the server to send = replies). The All DHCP
Agents address is link scoped, so the source address = only needs to be
linked scoped as well.

So, I don't see any issues here. Or am I failing to = understand your concern?

>
> - Using DUID, how the address selection is = done?
>
> BV> I don't understand what you are asking = here.
>
> - The draft  says that, when the = client  needs an  additional  temporary
> address, it can include OPTION_RTA encapsulated = in OPTION_IA and get the
> additional one.  This means, in the same = IA, any number of addresses can
> be can be added and deleted.  Will it hold = for normal addresses also?  I
> mean, for  additional  normal  = addresses,  whether the client has to use
> already  existing IA to get = additional  address (or) will it use a fresh
> IA?  I remember that, the answer i got for = this question 3-4 months back
> was that the client will use fresh IA,  = because,  adding  address to the
> same IA will lead  complexity.  Just = in curiosity, i am asking, why this
> complexity was introduced for temporary = addresses?  Why can't the client
> can ask additional temporary addresses in a = fresh IA?
>
> BV> We do NOT want IA explosion. Ideally, a = client should be able to use
> the same IA forever under "normal" = cases. A IA can have one or many
> addresses, addresses will come and go. Server = policy dictates the non-
> temporary addresses assigned to a client. = Client policy dictates the
> temporary address needs - hence the client must = have a way to say
> "give me more". For example, if a = client is running two applications that
> each want unique temporary addresses, it has to = request those from the
> server. Later, when a third application starts, = the client will need
> another address.
>
> - Can temporary  addresses and normal = addresses can co-exist in same IA?
> If yes, then, for renewal, does the client send = normal  addresses  alone
> in IA to the  server?  since,  = the  renewal of  temporary  addresses  is
> meaningless.
>
> BV> YES the can both be in the SAME IA. That = is the intention.
>
> - I thought for decreasing the load of server, = unlike DHCPv4, in DHCPv6,
> the dns  updates  was moved to  = client.  But, the draft  says  that, for
> temporary addresses, the server has to update = the DNS.  Why this feature
> was included in server, instead of = client?
>
> BV> What we say in section 14 is:
>
>    The server MAY update the DNS = for a temporary address as described in
>    section 4 of RFC3041, and = MUST NOT update the DNS in any other way
>    for a temporary = address.
>
> BV> This all depends how DDNS is handled = with DHCPv6 and who is doing the
> updates. We just wanted to be clear that if the = server was doing DDNS
> updates for the client, is must adhere to the = requirements of RFC 3041
> in doing them!!
>
> -  Why  only  temporary  = has  to be  updated  in  DNS?  why  = not  normal
> addresses?
>
> BV> See answer to previous question. DDNS = updates are still TBD. Likely
> the DHCPv4 FQDN option will be used (changing = the A processing to reflect
> AAAA processing and using the DUID for the = client identification).
>
> - I think for  updation,  we need to = define,  hostname/FQDN  option  for
> this.
>
> BV> Yes, we will need this.
>
> - How can the client  specify  the = number of address  it wants?  Will it
> send IA optio with 'n' number empty of IA_ADDR = option?  Instead of that,
> can we define  another  option  = OPT_RA  similar to OPT_RTA,  that can be
> encapsulated in OPT_IA?
>
> BV> The client can't specify how many = non-temporary addresses it wants.
> This is controlled by the server. The client = *CAN* use multiple IAs and
> if the server policy allows, that can easily be = used to give the clients
> LOTS of addresses (one set per IA).
>
> - Section 17.1.2 says that the client = collects  Advertise messages until
> SOL_TIMEOUT has elapsed.  Then, RT will = be  recalculated.  Now, does the
> client needs to retransmit the SOLICIT  = message?  If it is so, then, the
> same server will reply multiple times.  = But the retransmission algorithm
> in Section 15 says that, it should retransmit = the packet.
>
> BV> The client waits SOL_TIMEOUT but it does = not retransmit the Solicit
> if it has received at least one Advertise. = Retransmit Solicit only if no
> Advertise messages are received.

VB> The Algorithm in section 15 says that, it = should  retransmit  at the
expiration  on RT.  The  = variation  for  SOLICIT  on this  algorithm  = in
17.1.2, does not say  anything  about = this.  So, it is better to add the
statement  you have stated above, in the draft = also for better  clarity.
Otherwise, it is misleading.

BV2> I will review the text again to see if this = was not clear.

>
> - In  section  17.1.2, we need to add = a  sentence,  "When the RT reached
> MRT, if the one or more valid advertise  = message is obtained, the client
> should stop sending Advertise message and = proceed further with collected
> Advertise  message".  = Otherwise,  since MRC and MRD are 0, this  process
> will go infinetly  according to algorithm = specified in Section 15.  This
> is also an implementation problem we = faced.
>
> BV> Haven't studied this issue.
>
> - In some place, the server should fill = "server-address" with one of its
> address  based on the link in which the = packet is  received.  In another
> place, it is said that the  = server-address  field can be filled with the
> address configured by the administrator.  = What is the standard procedure
> to be followed?
>
> BV> We probably should clean up the text to = be consistent. I think the
> answer is use configured address if so = configured for that LINK, otherwise
> use one of the LINK interface addresses.
>
> - In Advertise,  should the server assign = all the addresses asked by the
> client?  (or) only few of them?
>
> BV> It depends on the server's = policies.
>
> - Till what  time,  these  = OFFERED  addresses  are  preserved  for = those
> clients to assign?
>
> BV> My opinion is that the ADVERTISED = addresses are just a possible set of
> addresses the client will get and may not be = the exact addresses. The client
> must wait until the Reply to the Request before = it knows which addresses it
> got and before it does Duplicate Address = Detection. The ADVERTISE should
> include all of the parameters the client is = likely to receive in the Reply,
> but they are just possible values and not the = actual values.

VB> What i am  asking  is, in V4,  = there  is a  concept  called  OFFERED
addresses, which will be reserved to a client.  = The server reserves that
addresses for the some predefined  time.  = At the expiration of the time,
if the client has not sent the  request,  = it will be  allocated  to some
other  clients.  I think,  if = we  follow  the  same  policy,  it will = be
better.  Assume, a client  sends a SOLICIT = and the server  replies  with
ADVERTISE  with some  addresses.  = Before the client sending the Request,
if some  other  client  = requests  for the  addresses,  with the  = current
mechanism,  the server will assign the  = addresses to new client.  It may
lead to server to send  AddrUnavail  to = the first  client, if the server
has only  limited  number  of  = addresses.  It will  lead to  unnecessary
packet transactions.

BV2> I don't agree. It is much better if the = server can just send something
out and not have to do anything to remember it. With = IPv6, what's the likelyhood
that an address won't be available - we have 2^64 = addresses on each prefix!

BV2> What I view the ADVERTISE message to be is = for the server to say I am
willing to give you this stuff [assuming it is = avaiable] but that I haven't
given you the EXACT stuff you will get (since that = happens in the Reply to
the Request).

BV2> BUT please note that this really is up to = each SERVER to do what it
wants. A SERVER can chose to ADVERTISE real stuff = and "reserve" it for some
period of time (and that is a SERVER implementation = issue). In my server,
I might chose that time to be 0 seconds. In your = server, you can set it to
1 hour. The client can't do anything with ADVERTISEd = information other than
make a decision based on which ADVERTISE it wants to = accept (assuming it gets
multiple). In any case, the information from the = Reply is what it must install.
So, this is purely a server implementation = issue.

>
> - If the server has fewer  addresses than = the client has asked, will the
> server assign fewer addresses or send = AddrUnavail?
>
> BV> I would only return AddrUnavail if NO = addresses are available. If you
> can assign some, give the client those. It can = make a decisions as to
> whether it wants to accept them or not.

VB> agreed.

>
> - The draft says that the renew  message = can be used for checking up the
> validity  of  the  other  = configuration  parameters.  For  checking  = the
> validity  of them, will the client  = send the option  codes in ORO option
> (or) send the parameters in their respective = options?
>
> BV> The Renew message does not need to = include those options (including
> them in an ORO is probably a good idea so the = server knows you want them).
> It is really the Reply that matters and the = server will Reply with the
> current settings. The client can then apply = those values. The server will
> (I suspect) not really check them - it just = Replies with the current
> values.

VB>  Sending  the ORO  option is = best  idea.  I think we need to add the
mechanism  of renewal of other  = parameters  (sending  ORO option) in the
draft.

BV2> Yeah, but that is already clear. See 22.6 = (ORO option) text. And also
Appendix B.

>
> - Should release/decline of addresses be done = for IA as whole?  (or) Can
> few addresses be relased from an IA? (partial = release)
>
> BV> Individual addresses can be released or = declined. The client MUST
> include the addresses to decline/release. The = server ignores any addresses
> that the client doesn't "own".
>
> - Assuming the client is sending  multiple = IAs for renewing,  the server
> finds that one particular IA is not found in = the client  bindings,  will
> it renews the remaining IAs? (or) will it send = NoBinding error?
>
> BV> It can send a NoBinding status for that = IA. (And renew the others.)
>
> - What will the client do, for the multiple IAs = sent for renew, only one
> IA is missing in the reply?
>
> BV> No sure what you asking? Is this a = follow up to the previous question?
> If the IA returns with a NoBinding status, the = client may either continue
> to use those addresses (since it must have = gotten them from someone in the
> past) or drop them (and the IA).
>
> - Can you explain the differnce between, = "configuration  information are
> not valid" and "configuration = information does not match".  In the first
> case, for Confirm  message  = ConfNoMatch is sent and for the next one, it
> is  sending  SUCCESS.  The draft = says that for  ConfNoMatch,  the client
> should  send renew  message.  If = the  configuration  parameters  are not
> matching, then what is the use of sending renew = message?
>
> BV> Have to look into this one more.
>
> - For the cases like, "conf parameters are = not valid", "conf  parameters
> does not match" and  = "prefix  does not match",  what will the server = do,
> for the release message?  What will the = server do? if (i) all, (ii) only
> few  addresses  are invalid.  = Will the server  release the address which
> are valid?
>
> BV> Have to look into this one more.
>
> - Section  21.6.5.5 says that, if the = client is not able to validate the
> authentication  for the REPLY  = message,  then it should  start  with the
> SOLICIT.  I feel that this is = inefficient,  instead, it can try the next
> available server which has sent the advertise = message.
>
> BV> Have to look into this one more.
>
> - In the previous  versions, we have  = Retransmission  Parameter  option.
> Why it was removed?
>
> BV> There are significant security / DOS = issues with allowing the server
> to set parameters. Also, there are issues as = when these parameters are to
> be used (vs the defaults). If a client moves to = a completely different
> DHCP domain, the parameters may not be valid = and how does it know that?

VB> Agreed

>
> - Some useful options were defined in DHCPv6 = extension draft.  When will
> those options be included in this draft?
>
> BV> Suggest the ones you want to have = included! Provide the text (if it
> needs to be revised). That's what Ralph (as = editor) has requested in the
> past.

VB> I think, there are some basic = configuration  parameters for the host
to work comfortably.  We can add options for = getting those configuration
parameters.  The options are,

NIS, NIS+, NTP server addresses, SLP DA addresses and = its scope list.
NIS and NIS+ client domain name, Time Zone.
hostname,FQDN,static route option.

If you are  agreeing in adding these  = options to base spec,i can provide
the text.

BV2> Supply proposed text (similar to the existing = Options sections). If you don't
supply it, the options won't be in the base spec. If = you do, it will just depend on
what the WG thinks of them. I don't really see any = significant reason not to include
the ones you propose. I think the major issue is to = have a clear reason for the option
and to assure it is well define/specified. One = tactic that has been used is to wait
to define the options until a clear need is found = (since then a clearer specification of
the option can be written!).

------_=_NextPart_001_01C19F82.4514F210-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 03:22:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03703; Fri, 18 Jan 2002 03:22:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29909; Fri, 18 Jan 2002 03:21:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29885 for ; Fri, 18 Jan 2002 03:21:30 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03687 for ; Fri, 18 Jan 2002 03:21:27 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0I8KsH64241; Fri, 18 Jan 2002 09:20:54 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 0BCD7C05B; Fri, 18 Jan 2002 09:20:25 +0100 (CET) Date: Fri, 18 Jan 2002 09:20:23 +0100 From: Martin Stiemerling To: Jim Bound Cc: dhcwg@ietf.org Subject: Re: [dhcwg] static route option for dhcpv6 Message-ID: <8140000.1011342023@elgar> In-Reply-To: References: X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit --On Donnerstag, Januar 17, 2002 12:29:00 -0500 Jim Bound wrote: > We need the static route option for the dentist office scenarios of IPv6 > where there are two lans and no routers or as VJ pointed out ipv6forwardin > g is turned on and not doing RAs. But doesn't an IPv6 router that isn't sending his router advertisements violate the IPv6 spec? In this case DHCPv6 should not support this feature in this way. > > We also want it for configured tunnels and its different than DSTM. Ok, I agree with using it for configured tunnels. But I would choose another name, like IPv4 Tunnel End Point. > > We should also keep it simple as a config parameter. Yes. > > I see no pain here and it is needed. Its a simple option to add and > necessary for early IPv6 deployment as VJ pointed out in first mails. > > regards, > > > /jim > > > On Thu, 17 Jan 2002, Vijay Bhaskar A K wrote: > >> Please see my comments inline. >> >> ~Vijay. >> >> > After thinking about this more and after seeing the other discussion >> > on this subject, I'm not sure exactly when or why this option would be >> > needed. But on the other than, it technically isn't needed in IPv4 >> > either because ICMP redirects and other routing table distribution >> > techniques exist and DHCPv4 does have such an option (and a revised >> > one to carry classless routes). >> > >> > So, we can do one of two things: >> > 1. Include it and consider DHCPv6 as a toolbox and those people that >> > want to use it (and those clients that want to support it) do so. For >> > example, Solaris 8 includes the route command and it supports IPv6 >> > routing table operations. Can anyone who has lots of experience with >> > IPv6 deployment indicate whether there is a need to statically add >> > routing table entries? 2. Wait until someone has a clear case of >> > needing it and have it defined in some future document. >> >> Assume the following scenaria. >> - There are 2 networks A and B. >> - There is a node n connected to both the network, and it has enabled >> ipv6-forwarding and not sending router advertisements. >> >> Now, a node in network A gets an address from the DHCPv6 server and now >> it wants to communicate with a node in network B. In the current >> scenario, the route has to be manually configured, then only, it will be >> able to contact the node in network B. With static route option, we can >> autoconfigure it. This will be more helpful in getting minimal >> configuration for smaller networks, which don't have any router >> advertisements and for the networks which have not completely deployed >> routing mechanisms. >> >> It will be useful in the getting the configured tunnels also. >> >> > >> > If we do want to include it, questions to ponder: >> > - Should any lifetimes be associated with the routes? Either one >> > lifetime for all routes or each route? - Should this option be >> > encapsulated within an IA? That way, it would be renewed with the IA. >> >> I think, we can treat this as another configuration parameter. We don't >> need to mix up with IA. If there are multiple IAs with same prefix, >> then this static route is common for all these IAs. Whenever there is a >> change in the static route, we can use reconfiguration mechanism to >> update it. >> >> > >> > I myself am leaning more towards recommending we wait until a need is >> > found. >> > >> > - Bernie >> > >> > >> > -----Original Message----- >> > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] >> > Sent: Wednesday, January 16, 2002 1:13 PM >> > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org >> > Subject: RE: [dhcwg] static route option for dhcpv6 >> > >> > >> > Bernie, >> > This option format looks ok for me. We can include it. >> > Vijay >> > >> >> >> -- >> ____Vijay_Bhaskar_A_K____ >> ______Inet_Services______ >> ________HP_ISO___________ >> ______Ph:_2051424________ >> ____Telnet:_847_1424_____ >> ___Pager:_9624_371137____ >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 03:22:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03710; Fri, 18 Jan 2002 03:22:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29966; Fri, 18 Jan 2002 03:22:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29940 for ; Fri, 18 Jan 2002 03:22:07 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03694 for ; Fri, 18 Jan 2002 03:22:04 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0I8M5H64249; Fri, 18 Jan 2002 09:22:05 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 8E6BDC05B; Fri, 18 Jan 2002 09:21:36 +0100 (CET) Date: Fri, 18 Jan 2002 09:21:34 +0100 From: Martin Stiemerling To: vijayak@india.hp.com, dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <8590000.1011342094@elgar> In-Reply-To: <001001c19eb9$f2211fc0$2f290a0f@india.hp.com> References: <001001c19eb9$f2211fc0$2f290a0f@india.hp.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Ok, plesse see me prior email. Martin --On Mittwoch, Januar 16, 2002 23:46:40 +0530 Vijayabhaskar A K wrote: > We can use this for forwarding from the network which > don't have any router advertisement, but has a node > in the network, attached to the another network and has > ip-forwarding enabled. > ~vijay > >> -----Original Message----- >> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of >> Martin Stiemerling >> Sent: Wednesday, January 16, 2002 5:56 PM >> To: vijayak@india.hp.com; dhcwg@ietf.org >> Subject: RE: [dhcwg] static route option for dhcpv6 >> >> >> >> In the case of no on-link router, no routes are required! >> > >> > In the absence of an on-link IPv6 router, hosts might use configured >> > tunnels to reach other IPv6 networks. Such routes can be sent in >> > static-route option. >> > >> >> Yes, this might be useful, but doesn't sound directly like >> > static routes, >> but more than transistioning mechanismen (IPv6 over IPv4 >> tunnel). There are >> two DSTM options in the draft, but they may not be sufficient >> for this >> purpose. >> >> Martin >> >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 12:39:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20254; Fri, 18 Jan 2002 12:39:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25950; Fri, 18 Jan 2002 12:35:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25921 for ; Fri, 18 Jan 2002 12:35:08 -0500 (EST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20042 for ; Fri, 18 Jan 2002 12:34:55 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel10.hp.com (Postfix) with ESMTP id E7AA9400A08; Fri, 18 Jan 2002 09:34:11 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id XAA16245; Fri, 18 Jan 2002 23:08:15 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201181738.XAA16245@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: Bernie.Volz@am1.ericsson.se Date: Fri, 18 Jan 2002 23:08:15 +0530 (IST) Cc: vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDB4@EAMBUNT705> from Bernie Volz at Jan "17," 2002 "12:10:39" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Bernie, See my comments prefixed by VB2> ~ Vijay > Vijay, see BV2> comments. > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Thursday, January 17, 2002 4:35 AM > To: Bernie.Volz@am1.ericsson.se > Cc: vijayak@india.hp.com; dhcwg@ietf.org > Subject: Re: [dhcwg] Comments on 22 rev of the draft > > > See my comments inline prefixed by VB> > > ~Vijay > > > Let me try to answer these based on my understanding/view of -22. > > > > See below. > > > > - Bernie > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Wednesday, January 16, 2002 1:05 PM > > To: dhcwg@ietf.org > > Cc: vijayak@dce.india.hp.com > > Subject: [dhcwg] Comments on 22 rev of the draft > > > > > > I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > > in telling the comments. > > > > - I think we need to fix the order of occurence some options that can > > appear in the dhcp messages. I think, the DUID option should occur > > before the IA option. This makes the processing simpler. > > > > BV> I think this would be good to say that a client MUST place the DUID option in a mesage before any IA options. > > > > - I didn't get, why the authentication option should be the last one. I > > feel like it should be the first one. If the server/client is not able > > to validate the authentication, it can straight away discard the packet > > without further processing. > > > > BV> I too wouldn't mind having this earlier. It makes it easier to validate messages since one doesn't have to process all of the options (or at least parse to some extent all of the options) before one can authenticate the message. But, I would call this a SHOULD not a MUST. > > VB> I would like to call this MUST rather than SHOULD, because, this > authentication model of DHCP came only for avoiding DoS attacks. The > server should not waste its time in processing these spurious packets. > > > > > - Section 13 says the ways for selecting addresses for assignment in > > IAs. Assume, the server has got a direct message from the client. The > > IP datagram source address is a site-local one. The message is received > > on the server's interface, which is configured with a global address. > > According to the draft, the server should assume that the client is on > > the link identified by the sitelocal address in datagram. Now, the > > problem arises, if the server is not configured for allocating > > site-local address for the link. Now, can the server assume, since the > > client has sent the direct message, it is on the same link as the server > > and assign it an address of global scope, with the same prefix of its > > received interface. I think, i have already raised the similar kind of > > problem previously, the answer i had got was to select address of global > > scope. Then, the server should not select the link based on the source > > address. This is an implementation problem we faced. FYI, HP has > > officially released DHCPv6. This implementation is based on 16th and > > some portion of 18th version of the draft. This software is freely > > available at http://software.hp.com/ You can download it and tell me > > your comments. > > > > BV> Section 13 tells how to determine the *LINK* the client is on. Once > > that has been done, you assign addresses based on the prefixes that the > > server has configured for that *LINK*. If the source address for the > > DHCP message was a link local, the server knows that it can't have come > > from anywhere but that link (since link-local are only valid locally). > > But this only determines the LINK for the client; not the addresses. > > VB> Assume the scenario where the server and client are in same link. > The configuration of server's interface and client interface is as > follows. > > server lan0 - fe80::260:b0ff:fec1:bb6b (A link local address) > server lan0:1 - 3ffe::12 (A global address) > client lan0 - fe80::210:83ff:fe18:886f (A link local address) > client lan0:1 - fec0::1234:27 (A site local address) > > server lan0 and client's lan0 are in same link. Now the client decides > to get an IP address from dhcp server. So, it puts the site local > address (lan0:1 addr) in the IP datagram src address field and sends the > SOLICIT message. Assume, the server is configured to allocate only > global address of prefix 3ffe::/64 for that link. But, according to the > draft, it finds out that the message comes from fec0::1234:27/64 > network, finds out it is not supposed to serve that network and hence it > does not send advertise. What i feel is, since the allocation for > normal addresses are dictated by server's policy, let the server dictate > completely. let it not to give any preference to client's wish. In the > above situation, if the server is not noticing the src address in IP > datagram of the client, it can find out that the client is on the same > link as the server, since it is a direct message. Thus, it can allocate > allocate address of prefix 3ffe::/64. Since the SOLICIT message is sent > to All DHCP Agents Address, if the server receives the client message > directly, then, the client is in the same link. Thus, the decision of > the link based on the IP datagram src address of the client is not at > all necessary. > > BV2> Again, all the server does is use the address to determine the LINK. > So, the server needs to know about the site local prefix being active on > the link but that's all. If the server fails to find the prefix for the > address, it can either drop the request or it could simply assume it must > have come from the LINKs associated with the interface the packet was > received on. So, it is happy. > > Note that the client really should be using the link local address UNLESS > it is unicasting to a server (in which case it must use an address of > sufficient scope valid for the server to send replies). The All DHCP > Agents address is link scoped, so the source address only needs to be > linked scoped as well. > > So, I don't see any issues here. Or am I failing to understand your concern? VB2> What i mean is, for finding the link, server should not trust client. It knows the link where it is received. Based on its own address in the link, it should allocate address to the client. The client may not be knowing where it is. Sometimes, what it has may be wrong. So, the src address in IP datagram may show wrong information. VB2> Assume, a client is moving from the 3ffe::/64 network to 5ffe::/64 network. As per the draft, it will the confirm message. 16.2.2 says that, the server will just compare the binding info it's having with the one in confirm message. I think the server MUST check the prefix also. It must check whether the addresses in the IA are having the same prefixes of the link in which the client is connected to. I think, no where in the draft, the draft is not dealing with the prefix comparison of the link and IA addresses. So, in this case, the server sends a positive reply. The client wont get it, because, it does have a valid address to receive it. VB2> After some time, if it requires another address, it will send a new request with the src address with 3ffe::/64 prefix and hence the server allocates the address with 3ffe::/64 prefix for the 5ffe::/64 network. I think the neat and clean way of client asking for the addresses in a particular prefix, is sending through an option, similar to subnet selection option (RFC 3011). I can include the text for this option. This is one of the option, i have forgetten to tell in the previous mail. > > > > > - Using DUID, how the address selection is done? > > > > BV> I don't understand what you are asking here. > > > > - The draft says that, when the client needs an additional temporary > > address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > > additional one. This means, in the same IA, any number of addresses can > > be can be added and deleted. Will it hold for normal addresses also? I > > mean, for additional normal addresses, whether the client has to use > > already existing IA to get additional address (or) will it use a fresh > > IA? I remember that, the answer i got for this question 3-4 months back > > was that the client will use fresh IA, because, adding address to the > > same IA will lead complexity. Just in curiosity, i am asking, why this > > complexity was introduced for temporary addresses? Why can't the client > > can ask additional temporary addresses in a fresh IA? > > > > BV> We do NOT want IA explosion. Ideally, a client should be able to use > > the same IA forever under "normal" cases. A IA can have one or many > > addresses, addresses will come and go. Server policy dictates the non- > > temporary addresses assigned to a client. Client policy dictates the > > temporary address needs - hence the client must have a way to say > > "give me more". For example, if a client is running two applications that > > each want unique temporary addresses, it has to request those from the > > server. Later, when a third application starts, the client will need > > another address. > > > > - Can temporary addresses and normal addresses can co-exist in same IA? > > If yes, then, for renewal, does the client send normal addresses alone > > in IA to the server? since, the renewal of temporary addresses is > > meaningless. > > > > BV> YES the can both be in the SAME IA. That is the intention. > > > > - I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > > the dns updates was moved to client. But, the draft says that, for > > temporary addresses, the server has to update the DNS. Why this feature > > was included in server, instead of client? > > > > BV> What we say in section 14 is: > > > > The server MAY update the DNS for a temporary address as described in > > section 4 of RFC3041, and MUST NOT update the DNS in any other way > > for a temporary address. > > > > BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > > updates. We just wanted to be clear that if the server was doing DDNS > > updates for the client, is must adhere to the requirements of RFC 3041 > > in doing them!! > > > > - Why only temporary has to be updated in DNS? why not normal > > addresses? > > > > BV> See answer to previous question. DDNS updates are still TBD. Likely > > the DHCPv4 FQDN option will be used (changing the A processing to reflect > > AAAA processing and using the DUID for the client identification). > > > > - I think for updation, we need to define, hostname/FQDN option for > > this. > > > > BV> Yes, we will need this. > > > > - How can the client specify the number of address it wants? Will it > > send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > > can we define another option OPT_RA similar to OPT_RTA, that can be > > encapsulated in OPT_IA? > > > > BV> The client can't specify how many non-temporary addresses it wants. > > This is controlled by the server. The client *CAN* use multiple IAs and > > if the server policy allows, that can easily be used to give the clients > > LOTS of addresses (one set per IA). > > > > - Section 17.1.2 says that the client collects Advertise messages until > > SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > > client needs to retransmit the SOLICIT message? If it is so, then, the > > same server will reply multiple times. But the retransmission algorithm > > in Section 15 says that, it should retransmit the packet. > > > > BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > > if it has received at least one Advertise. Retransmit Solicit only if no > > Advertise messages are received. > > VB> The Algorithm in section 15 says that, it should retransmit at the > expiration on RT. The variation for SOLICIT on this algorithm in > 17.1.2, does not say anything about this. So, it is better to add the > statement you have stated above, in the draft also for better clarity. > Otherwise, it is misleading. > > BV2> I will review the text again to see if this was not clear. > > > > > - In section 17.1.2, we need to add a sentence, "When the RT reached > > MRT, if the one or more valid advertise message is obtained, the client > > should stop sending Advertise message and proceed further with collected > > Advertise message". Otherwise, since MRC and MRD are 0, this process > > will go infinetly according to algorithm specified in Section 15. This > > is also an implementation problem we faced. > > > > BV> Haven't studied this issue. > > > > - In some place, the server should fill "server-address" with one of its > > address based on the link in which the packet is received. In another > > place, it is said that the server-address field can be filled with the > > address configured by the administrator. What is the standard procedure > > to be followed? > > > > BV> We probably should clean up the text to be consistent. I think the > > answer is use configured address if so configured for that LINK, otherwise > > use one of the LINK interface addresses. > > > > - In Advertise, should the server assign all the addresses asked by the > > client? (or) only few of them? > > > > BV> It depends on the server's policies. > > > > - Till what time, these OFFERED addresses are preserved for those > > clients to assign? > > > > BV> My opinion is that the ADVERTISED addresses are just a possible set of > > addresses the client will get and may not be the exact addresses. The client > > must wait until the Reply to the Request before it knows which addresses it > > got and before it does Duplicate Address Detection. The ADVERTISE should > > include all of the parameters the client is likely to receive in the Reply, > > but they are just possible values and not the actual values. > > VB> What i am asking is, in V4, there is a concept called OFFERED > addresses, which will be reserved to a client. The server reserves that > addresses for the some predefined time. At the expiration of the time, > if the client has not sent the request, it will be allocated to some > other clients. I think, if we follow the same policy, it will be > better. Assume, a client sends a SOLICIT and the server replies with > ADVERTISE with some addresses. Before the client sending the Request, > if some other client requests for the addresses, with the current > mechanism, the server will assign the addresses to new client. It may > lead to server to send AddrUnavail to the first client, if the server > has only limited number of addresses. It will lead to unnecessary > packet transactions. > > BV2> I don't agree. It is much better if the server can just send something > out and not have to do anything to remember it. With IPv6, what's the likelyhood > that an address won't be available - we have 2^64 addresses on each prefix! > > BV2> What I view the ADVERTISE message to be is for the server to say I am > willing to give you this stuff [assuming it is avaiable] but that I haven't > given you the EXACT stuff you will get (since that happens in the Reply to > the Request). > > BV2> BUT please note that this really is up to each SERVER to do what it > wants. A SERVER can chose to ADVERTISE real stuff and "reserve" it for some > period of time (and that is a SERVER implementation issue). In my server, > I might chose that time to be 0 seconds. In your server, you can set it to > 1 hour. The client can't do anything with ADVERTISEd information other than > make a decision based on which ADVERTISE it wants to accept (assuming it gets > multiple). In any case, the information from the Reply is what it must install. > So, this is purely a server implementation issue. VB2> Yes. I agree that this is purely an implementation issue. > > > > > - If the server has fewer addresses than the client has asked, will the > > server assign fewer addresses or send AddrUnavail? > > > > BV> I would only return AddrUnavail if NO addresses are available. If you > > can assign some, give the client those. It can make a decisions as to > > whether it wants to accept them or not. > > VB> agreed. > > > > > - The draft says that the renew message can be used for checking up the > > validity of the other configuration parameters. For checking the > > validity of them, will the client send the option codes in ORO option > > (or) send the parameters in their respective options? > > > > BV> The Renew message does not need to include those options (including > > them in an ORO is probably a good idea so the server knows you want them). > > It is really the Reply that matters and the server will Reply with the > > current settings. The client can then apply those values. The server will > > (I suspect) not really check them - it just Replies with the current > > values. > > VB> Sending the ORO option is best idea. I think we need to add the > mechanism of renewal of other parameters (sending ORO option) in the > draft. > > BV2> Yeah, but that is already clear. See 22.6 (ORO option) text. And also > Appendix B VB2> Agreed > > few addresses be relased from an IA? (partial release) > > > > BV> Individual addresses can be released or declined. The client MUST > > include the addresses to decline/release. The server ignores any addresses > > that the client doesn't "own". > > > > - Assuming the client is sending multiple IAs for renewing, the server > > finds that one particular IA is not found in the client bindings, will > > it renews the remaining IAs? (or) will it send NoBinding error? > > > > BV> It can send a NoBinding status for that IA. (And renew the others.) > > > > - What will the client do, for the multiple IAs sent for renew, only one > > IA is missing in the reply? > > > > BV> No sure what you asking? Is this a follow up to the previous question? > > If the IA returns with a NoBinding status, the client may either continue > > to use those addresses (since it must have gotten them from someone in the > > past) or drop them (and the IA). > > > > - Can you explain the differnce between, "configuration information are > > not valid" and "configuration information does not match". In the first > > case, for Confirm message ConfNoMatch is sent and for the next one, it > > is sending SUCCESS. The draft says that for ConfNoMatch, the client > > should send renew message. If the configuration parameters are not > > matching, then what is the use of sending renew message? > > > > BV> Have to look into this one more. > > > > - For the cases like, "conf parameters are not valid", "conf parameters > > does not match" and "prefix does not match", what will the server do, > > for the release message? What will the server do? if (i) all, (ii) only > > few addresses are invalid. Will the server release the address which > > are valid? > > > > BV> Have to look into this one more. > > > > - Section 21.6.5.5 says that, if the client is not able to validate the > > authentication for the REPLY message, then it should start with the > > SOLICIT. I feel that this is inefficient, instead, it can try the next > > available server which has sent the advertise message. > > > > BV> Have to look into this one more. > > > > - In the previous versions, we have Retransmission Parameter option. > > Why it was removed? > > > > BV> There are significant security / DOS issues with allowing the server > > to set parameters. Also, there are issues as when these parameters are to > > be used (vs the defaults). If a client moves to a completely different > > DHCP domain, the parameters may not be valid and how does it know that? > > VB> Agreed > > > > > - Some useful options were defined in DHCPv6 extension draft. When will > > those options be included in this draft? > > > > BV> Suggest the ones you want to have included! Provide the text (if it > > needs to be revised). That's what Ralph (as editor) has requested in the > > past. > > VB> I think, there are some basic configuration parameters for the host > to work comfortably. We can add options for getting those configuration > parameters. The options are, > > NIS, NIS+, NTP server addresses, SLP DA addresses and its scope list. > NIS and NIS+ client domain name, Time Zone. > hostname,FQDN,static route option. > > If you are agreeing in adding these options to base spec,i can provide > the text. > > BV2> Supply proposed text (similar to the existing Options sections). If you don't > supply it, the options won't be in the base spec. If you do, it will just depend on > what the WG thinks of them. I don't really see any significant reason not to include > the ones you propose. I think the major issue is to have a clear reason for the option > and to assure it is well define/specified. One tactic that has been used is to wait > to define the options until a clear need is found (since then a clearer specification of > the option can be written!). VB2> I am sending it in a seperate mail. -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 12:59:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21143; Fri, 18 Jan 2002 12:59:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26564; Fri, 18 Jan 2002 12:57:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26478 for ; Fri, 18 Jan 2002 12:57:53 -0500 (EST) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21039 for ; Fri, 18 Jan 2002 12:57:49 -0500 (EST) Received: from dce.india.hp.com (unknown [15.10.45.122]) by atlrel7.hp.com (Postfix) with ESMTP id 13805E00474; Fri, 18 Jan 2002 12:57:16 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id XAA16470; Fri, 18 Jan 2002 23:31:22 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201181801.XAA16470@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: Bernie.Volz@am1.ericsson.se Date: Fri, 18 Jan 2002 23:31:21 +0530 (IST) Cc: vijayak@india.hp.com, rdroms@cisco.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDB6@EAMBUNT705> from Bernie Volz at Jan "17," 2002 "12:40:56" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Bernie, See my comments prefixed by VB3. ~ Vijay > Vijay: > > Again, my comments are BV3. (I still have to look into the few that I previously flagged as such.) > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Thursday, January 17, 2002 5:45 AM > To: rdroms@cisco.com > Cc: vijayak@india.hp.com; Bernie.Volz@am1.ericsson.se; dhcwg@ietf.org > Subject: Re: [dhcwg] Comments on 22 rev of the draft > > > See my reply inline. > > ~Vijay > > > My thoughts on these issues... > > > > - Ralph > > > > At 01:08 PM 1/16/2002 -0600, Bernie Volz (EUD) wrote: > > > > >Let me try to answer these based on my understanding/view of -22. > > > > > >See below. > > > > > >- Bernie > > > > > >-----Original Message----- > > >From: Vijay Bhaskar A K > > >[mailto:vijayak@india.hp.com] > > >Sent: Wednesday, January 16, 2002 1:05 PM > > >To: dhcwg@ietf.org > > >Cc: vijayak@dce.india.hp.com > > >Subject: [dhcwg] Comments on 22 rev of the draft > > > > > >I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > > >in telling the comments. > > > > > >- I think we need to fix the order of occurence some options that can > > >appear in the dhcp messages. I think, the DUID option should occur > > >before the IA option. This makes the processing simpler. > > > > > >BV> I think this would be good to say that a client MUST place the DUID > > >option in a mesage before any IA options. > > > > RD - I'm willing to put in the text, but I don't see how it makes the > > processing easier. > > VB> If DUID occurs before the IA option, then, it will be easier to > locate the bindings of the client and then process the IA by IA. > > > > > >- I didn't get, why the authentication option should be the last one. I > > >feel like it should be the first one. If the server/client is not able > > >to validate the authentication, it can straight away discard the packet > > >without further processing. > > > > > >BV> I too wouldn't mind having this earlier. It makes it easier to > > >validate messages since one doesn't have to process all of the options (or > > >at least parse to some extent all of the options) before one can > > >authenticate the message. But, I would call this a SHOULD not a MUST. > > > > RD - I'm willing to make this change. > > > > >v- Section 13 says the ways for selecting addresses for assignment in > > >IAs. Assume, the server has got a direct message from the client. The > > >IP datagram source address is a site-local one. The message is received > > >on the server's interface, which is configured with a global address. > > >According to the draft, the server should assume that the client is on > > >the link identified by the sitelocal address in datagram. Now, the > > >problem arises, if the server is not configured for allocating > > >site-local address for the link. Now, can the server assume, since the > > >client has sent the direct message, it is on the same link as the server > > >and assign it an address of global scope, with the same prefix of its > > >received interface. I think, i have already raised the similar kind of > > >problem previously, the answer i had got was to select address of global > > >scope. Then, the server should not select the link based on the source > > >address. This is an implementation problem we faced. FYI, HP has > > >officially released DHCPv6. This implementation is based on 16th and > > >some portion of 18th version of the draft. This software is freely > > >available at http://software.hp.com/ You > > >can download it and tell me > > >your comments. > > > > > >BV> Section 13 tells how to determine the *LINK* the client is on. Once > > >that has been done, you assign addresses based on the prefixes that the > > >server has configured for that *LINK*. If the source address for the > > >DHCP message was a link local, the server knows that it can't have come > > >from anywhere but that link (since link-local are only valid locally). > > >But this only determines the LINK for the client; not the addresses. > > > > RD - To expand on Bernie's response, the server is free to assign > > an address according to whatever rules it might be configure with, > > once the server has determined the link to which the client is > > attached. > > > > >- Using DUID, how the address selection is done? > > > > > >BV> I don't understand what you are asking here. > > > > RD - It's possible to encode a rule for address assignment > > based on DUID, which would be what is sometimes called a > > "reservation" in some DHCPv4 servers. > > > > >- The draft says that, when the client needs an additional temporary > > >address, it can include OPTION_RTA encapsulated in OPTION_IA and get the > > >additional one. This means, in the same IA, any number of addresses can > > >be can be added and deleted. Will it hold for normal addresses also? I > > >mean, for additional normal addresses, whether the client has to use > > >already existing IA to get additional address (or) will it use a fresh > > >IA? I remember that, the answer i got for this question 3-4 months back > > >was that the client will use fresh IA, because, adding address to the > > >same IA will lead complexity. Just in curiosity, i am asking, why this > > >complexity was introduced for temporary addresses? Why can't the client > > >can ask additional temporary addresses in a fresh IA? > > > > > >BV> We do NOT want IA explosion. Ideally, a client should be able to use > > >the same IA forever under "normal" cases. A IA can have one or many > > >addresses, addresses will come and go. Server policy dictates the non- > > >temporary addresses assigned to a client. Client policy dictates the > > >temporary address needs - hence the client must have a way to say > > >"give me more". For example, if a client is running two applications that > > >each want unique temporary addresses, it has to request those from the > > >server. Later, when a third application starts, the client will need > > >another address. > > > > RD - The complexity comes not so much from adding an address > > to an IA as from the semantics of how to request that the > > server add a new address to an IA. So, a server can replace > > temporary addresses in an IA as lifetimes on existing addresses > > expire; if a client wants more addresses, it sends a new IA. > > VB> We can use similar option like OPT_RTA. If all the additional > addresses obtained are added to same IA, then we can do renew in one > short. Thus, preventing, multiple renew messages going to server. > > > > > >- Can temporary addresses and normal addresses can co-exist in same IA? > > >If yes, then, for renewal, does the client send normal addresses alone > > >in IA to the server? since, the renewal of temporary addresses is > > >meaningless. > > > > > >BV> YES the can both be in the SAME IA. That is the intention. > > > > RD - Agreed. > > > > >- I thought for decreasing the load of server, unlike DHCPv4, in DHCPv6, > > >the dns updates was moved to client. But, the draft says that, for > > >temporary addresses, the server has to update the DNS. Why this feature > > >was included in server, instead of client? > > > > > >BV> What we say in section 14 is: > > > > > > The server MAY update the DNS for a temporary address as described in > > > section 4 of RFC3041, and MUST NOT update the DNS in any other way > > > for a temporary address. > > > > > >BV> This all depends how DDNS is handled with DHCPv6 and who is doing the > > >updates. We just wanted to be clear that if the server was doing DDNS > > >updates for the client, is must adhere to the requirements of RFC 3041 > > >in doing them!! > > > > RD - Registering a temporary address in DNS defeats the anonymity > > provided by that address. Clients won't want to register temporary > > addresses; a server may register according to the rules > > in RFC3041. > > > > >- Why only temporary has to be updated in DNS? why not normal > > >addresses? > > > > > >BV> See answer to previous question. DDNS updates are still TBD. Likely > > >the DHCPv4 FQDN option will be used (changing the A processing to reflect > > >AAAA processing and using the DUID for the client identification). > > > > RD - Agreed. > > VB> Firstly, in most of the places, i am not able to identify whether you are agreeing my comments or bernie's. > > BV3> I believe Ralph is agreeing with me (at least I hope so!). > > > > > >- I think for updation, we need to define, hostname/FQDN option for > > >this. > > > > > >BV> Yes, we will need this. > > > > RD - Agreed. > > > > >- How can the client specify the number of address it wants? Will it > > >send IA optio with 'n' number empty of IA_ADDR option? Instead of that, > > >can we define another option OPT_RA similar to OPT_RTA, that can be > > >encapsulated in OPT_IA? > > > > > >BV> The client can't specify how many non-temporary addresses it wants. > > >This is controlled by the server. The client *CAN* use multiple IAs and > > >if the server policy allows, that can easily be used to give the clients > > >LOTS of addresses (one set per IA). > > > > RD - Agreed. > > > > >- Section 17.1.2 says that the client collects Advertise messages until > > >SOL_TIMEOUT has elapsed. Then, RT will be recalculated. Now, does the > > >client needs to retransmit the SOLICIT message? If it is so, then, the > > >same server will reply multiple times. But the retransmission algorithm > > >in Section 15 says that, it should retransmit the packet. > > > > > >BV> The client waits SOL_TIMEOUT but it does not retransmit the Solicit > > >if it has received at least one Advertise. Retransmit Solicit only if no > > >Advertise messages are received. > > > > RD - Agreed. > > > > >- In section 17.1.2, we need to add a sentence, "When the RT reached > > >MRT, if the one or more valid advertise message is obtained, the client > > >should stop sending Advertise message and proceed further with collected > > >Advertise message". Otherwise, since MRC and MRD are 0, this process > > >will go infinetly according to algorithm specified in Section 15. This > > >is also an implementation problem we faced. > > > > > >BV> Haven't studied this issue. > > > > RD - I don't understand the way you've explained the issue. If > > the client has received an Advertise message, it will terminate > > the retransmission process and accept the Advertise message. > > VB> We need to be more specific. The algorithm in Section 15 says, if > MRC and MRD are 0, the transaction is infinite until the reply is > obtained. The variation of this algorithm in 17.1.2 says that, the > client should be waiting in collecting the advertise messages even if it > has received advertise message. And, it does not say at what time, the > client should stop collecting the advertise message. So, this text has > to be added. > > BV3> Ah, but a reply (lower case r) - Advertise in this case - HAS been > received, so retransmission would stop. It is just that the client doesn't > continue processing immediately by Requesting ... instead it waits for > more Advertises to arrive. VB3> waits till what time? VB3> Even the first Advertise is also a reply. It should not stop the transacation. The end is defined by MRT. Please note that, for Reply, the end of the transaction is based on reply received. But, for the Advertise, the end of the transaction is based on the time MRT. VB3> Whatever i am argueing may be silly. But, if we are not very specific, there are lot of chances of assuming something else. VB3> I think there should be some text saying that, "The algorithm for SOLICIT transmission is a variation of the algorithm in Sec 15. Everything is same as 15, except, (i) the client should not retransmit the SOLICIT after a valid Advertise message is received. (ii) the whole transaction should stop, when RT becomes greater than MRT, provided, atleast one valid Advertise is received. > > > > > >- In some place, the server should fill "server-address" with one of its > > >address based on the link in which the packet is received. In another > > >place, it is said that the server-address field can be filled with the > > >address configured by the administrator. What is the standard procedure > > >to be followed? > > > > > >BV> We probably should clean up the text to be consistent. I think the > > >answer is use configured address if so configured for that LINK, otherwise > > >use one of the LINK interface addresses. > > > > RD - OK... > > > > >- In Advertise, should the server assign all the addresses asked by the > > >client? (or) only few of them? > > > > > >BV> It depends on the server's policies. > > > > RD - Agreed. > > > > >- Till what time, these OFFERED addresses are preserved for those > > >clients to assign? > > > > > >BV> My opinion is that the ADVERTISED addresses are just a possible set of > > >addresses the client will get and may not be the exact addresses. The client > > >must wait until the Reply to the Request before it knows which addresses it > > >got and before it does Duplicate Address Detection. The ADVERTISE should > > >include all of the parameters the client is likely to receive in the Reply, > > >but they are just possible values and not the actual values. > > > > RD - Agreed; the intention is that the Advertise message is > > advisory and not a firm promise of addresses to be assigned to > > the client. > > VB> Please refer my reply to bernie's mail... > > > > > >- If the server has fewer addresses than the client has asked, will the > > >server assign fewer addresses or send AddrUnavail? > > > > > >BV> I would only return AddrUnavail if NO addresses are available. If you > > >can assign some, give the client those. It can make a decisions as to > > >whether it wants to accept them or not. > > > > RD - Agreed. > > > > >- The draft says that the renew message can be used for checking up the > > >validity of the other configuration parameters. For checking the > > >validity of them, will the client send the option codes in ORO option > > >(or) send the parameters in their respective options? > > > > > >BV> The Renew message does not need to include those options (including > > >them in an ORO is probably a good idea so the server knows you want them). > > >It is really the Reply that matters and the server will Reply with the > > >current settings. The client can then apply those values. The server will > > >(I suspect) not really check them - it just Replies with the current > > >values. > > > > RD - Agreed. > > > > >- Should release/decline of addresses be done for IA as whole? (or) Can > > >few addresses be relased from an IA? (partial release) > > > > > >BV> Individual addresses can be released or declined. The client MUST > > >include the addresses to decline/release. The server ignores any addresses > > >that the client doesn't "own". > > > > RD - Agreed. > > > > >- Assuming the client is sending multiple IAs for renewing, the server > > >finds that one particular IA is not found in the client bindings, will > > >it renews the remaining IAs? (or) will it send NoBinding error? > > > > > >BV> It can send a NoBinding status for that IA. (And renew the others.) > > > > RD - Agreed. > > > > >- What will the client do, for the multiple IAs sent for renew, only one > > >IA is missing in the reply? > > > > > >BV> No sure what you asking? Is this a follow up to the previous question? > > >If the IA returns with a NoBinding status, the client may either continue > > >to use those addresses (since it must have gotten them from someone in the > > >past) or drop them (and the IA). > > > > RD - I agree; the client can continue to use the addresses in the > > un-Renew-ed IA until the lifetimes for those addresses expire. > > > > >- Can you explain the differnce between, "configuration information are > > >not valid" and "configuration information does not match". In the first > > >case, for Confirm message ConfNoMatch is sent and for the next one, it > > >is sending SUCCESS. The draft says that for ConfNoMatch, the client > > >should send renew message. If the configuration parameters are not > > >matching, then what is the use of sending renew message? > > > > > >BV> Have to look into this one more. > > > > > >- For the cases like, "conf parameters are not valid", "conf parameters > > >does not match" and "prefix does not match", what will the server do, > > >for the release message? What will the server do? if (i) all, (ii) only > > >few addresses are invalid. Will the server release the address which > > >are valid? > > > > > >BV> Have to look into this one more. > > > > > >- Section 21.6.5.5 says that, if the client is not able to validate the > > >authentication for the REPLY message, then it should start with the > > >SOLICIT. I feel that this is inefficient, instead, it can try the next > > >available server which has sent the advertise message. > > > > > >BV> Have to look into this one more. > > > > > >- In the previous versions, we have Retransmission Parameter option. > > >Why it was removed? > > > > > >BV> There are significant security / DOS issues with allowing the server > > >to set parameters. Also, there are issues as when these parameters are to > > >be used (vs the defaults). If a client moves to a completely different > > >DHCP domain, the parameters may not be valid and how does it know that? > > > > RD - Agreed; in fact, when a client moves to a new link (which is > > the case in which the Retransmission Parameter option would be used > > to change the client's behavior for the new link), it's too late > > because the client has potentially already used the retransmission > > mechanism on the new link, using the parameters from the old link. > > > > >- Some useful options were defined in DHCPv6 extension draft. When will > > >those options be included in this draft? > > > > > >BV> Suggest the ones you want to have included! Provide the text (if it > > >needs to be revised). That's what Ralph (as editor) has requested in the > > >past. > > > > RD - Please do send requests for other options. > > > > >I have found some typos in the draft. > > > > > >- In section 7.3, for reconfigure message, the client should intiate, > > >Renew/Reply not the Request/Reply > > > > > >- In 19.2, it is saying that, for Inform message, all the IAs to be > > >included. This a simple cut-paste problem. > > > > > >- 19.3.4 says, "The client uses the same variables and retransmission > > >algorithm as it does with Rebind or Information....". It should be > > >"Renew or Information..." > > > > > >- In 22.14, the server address field in Server Unicast Option is missing. > > > > > >- In 22.19, User class option message format looks messy, because of > > >some sentences in between. > > > > RD - I'll fix these in the -23 rev of the draft. > > > > > > >Regards > > >Vijay > > > > > >-- > > >____Vijay_Bhaskar_A_K____ > > >________HP_ESDI__________ > > >___Ph:_91_080_2051424____ > > >____Telnet:_847_1424_____ > > >___Pager:_9624_371137____ > > > > > >_______________________________________________ > > >dhcwg mailing list > > >dhcwg@ietf.org > > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ______Ph:_2051424________ > ____Telnet:_847_1424_____ > ___Pager:_9624_371137____ -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 13:06:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21349; Fri, 18 Jan 2002 13:06:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27093; Fri, 18 Jan 2002 13:04:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27072 for ; Fri, 18 Jan 2002 13:04:50 -0500 (EST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21275 for ; Fri, 18 Jan 2002 13:04:47 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel6.hp.com (Postfix) with ESMTP id 05F6660019B; Fri, 18 Jan 2002 13:04:14 -0500 (EST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id XAA23899; Fri, 18 Jan 2002 23:29:52 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Martin Stiemerling'" , "'Jim Bound'" Cc: Subject: RE: [dhcwg] static route option for dhcpv6 Date: Fri, 18 Jan 2002 23:35:09 +0530 Message-ID: <000901c1a04a$aba84400$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <8140000.1011342023@elgar> Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Martin Stiemerling > Sent: Friday, January 18, 2002 1:50 PM > To: Jim Bound > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] static route option for dhcpv6 > > > > > --On Donnerstag, Januar 17, 2002 12:29:00 -0500 Jim Bound > wrote: > > > We need the static route option for the dentist office > scenarios of IPv6 > > where there are two lans and no routers or as VJ pointed > out ipv6forwardin > > g is turned on and not doing RAs. > > But doesn't an IPv6 router that isn't sending his router > advertisements > violate the IPv6 spec? In this case DHCPv6 should not support > this feature > in this way. Please note that, there are no routers in the networks. That's why i mentioned that node as the one conneceted to two network and having ipv6forwarding enabled, instead of routers. This is for the networks which have not deployed IPv6 routing completely. I think there is no harm in having this option. > > > > We also want it for configured tunnels and its different than DSTM. > > Ok, I agree with using it for configured tunnels. But I would choose > another name, like IPv4 Tunnel End Point. > > > > > We should also keep it simple as a config parameter. > > Yes. > > > > > I see no pain here and it is needed. Its a simple option to add and > > necessary for early IPv6 deployment as VJ pointed out in > first mails. > > > > regards, > > > > > > /jim > > > > > > On Thu, 17 Jan 2002, Vijay Bhaskar A K wrote: > > > >> Please see my comments inline. > >> > >> ~Vijay. > >> > >> > After thinking about this more and after seeing the > other discussion > >> > on this subject, I'm not sure exactly when or why this > option would be > >> > needed. But on the other than, it technically isn't > needed in IPv4 > >> > either because ICMP redirects and other routing table > distribution > >> > techniques exist and DHCPv4 does have such an option > (and a revised > >> > one to carry classless routes). > >> > > >> > So, we can do one of two things: > >> > 1. Include it and consider DHCPv6 as a toolbox and those > people that > >> > want to use it (and those clients that want to support > it) do so. For > >> > example, Solaris 8 includes the route command and it > supports IPv6 > >> > routing table operations. Can anyone who has lots of > experience with > >> > IPv6 deployment indicate whether there is a need to > statically add > >> > routing table entries? 2. Wait until someone has a clear case of > >> > needing it and have it defined in some future document. > >> > >> Assume the following scenaria. > >> - There are 2 networks A and B. > >> - There is a node n connected to both the network, and > it has enabled > >> ipv6-forwarding and not sending router advertisements. > >> > >> Now, a node in network A gets an address from the DHCPv6 > server and now > >> it wants to communicate with a node in network B. > In the current > >> scenario, the route has to be manually configured, then > only, it will be > >> able to contact the node in network B. With static route > option, we can > >> autoconfigure it. This will be more helpful in > getting minimal > >> configuration for smaller networks, which don't > have any router > >> advertisements and for the networks which have not > completely deployed > >> routing mechanisms. > >> > >> It will be useful in the getting the configured tunnels also. > >> > >> > > >> > If we do want to include it, questions to ponder: > >> > - Should any lifetimes be associated with the routes? Either one > >> > lifetime for all routes or each route? - Should this option be > >> > encapsulated within an IA? That way, it would be renewed > with the IA. > >> > >> I think, we can treat this as another configuration > parameter. We don't > >> need to mix up with IA. If there are multiple IAs with > same prefix, > >> then this static route is common for all these IAs. > Whenever there is a > >> change in the static route, we can use reconfiguration > mechanism to > >> update it. > >> > >> > > >> > I myself am leaning more towards recommending we wait > until a need is > >> > found. > >> > > >> > - Bernie > >> > > >> > > >> > -----Original Message----- > >> > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > >> > Sent: Wednesday, January 16, 2002 1:13 PM > >> > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org > >> > Subject: RE: [dhcwg] static route option for dhcpv6 > >> > > >> > > >> > Bernie, > >> > This option format looks ok for me. We can include it. > >> > Vijay > >> > > >> > >> > >> -- > >> ____Vijay_Bhaskar_A_K____ > >> ______Inet_Services______ > >> ________HP_ISO___________ > >> ______Ph:_2051424________ > >> ____Telnet:_847_1424_____ > >> ___Pager:_9624_371137____ > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 15:34:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26085; Fri, 18 Jan 2002 15:34:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03004; Fri, 18 Jan 2002 15:26:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02977 for ; Fri, 18 Jan 2002 15:26:17 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25843 for ; Fri, 18 Jan 2002 15:26:13 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-326.cisco.com [10.82.241.70]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA12232; Fri, 18 Jan 2002 12:23:44 -0800 (PST) Message-Id: <4.3.2.7.2.20020118151943.01892130@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jan 2002 15:22:36 -0500 To: From: John Schnizlein Subject: RE: [dhcwg] static route option for dhcpv6 Cc: "'Martin Stiemerling'" , "'Jim Bound'" , In-Reply-To: <000901c1a04a$aba84400$2f290a0f@india.hp.com> References: <8140000.1011342023@elgar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 01:05 PM 1/18/2002, Vijayabhaskar A K wrote: >Please note that, there are no routers in the networks. That's why >i mentioned that node as the one conneceted to two network and having >ipv6forwarding enabled, instead of routers. This is for the networks >which have not deployed IPv6 routing completely. I think there is no >harm in having this option. If the purpose of the option is to enable situations where hosts have ipv6forwarding enabled, but do not act as proper v6 routers, then we should not support it. That is just bad practice. (IMHO) The use for tunnelling might be justifiable. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 15:54:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26557; Fri, 18 Jan 2002 15:54:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03960; Fri, 18 Jan 2002 15:48:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03926 for ; Fri, 18 Jan 2002 15:48:18 -0500 (EST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26384 for ; Fri, 18 Jan 2002 15:48:14 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel13.hp.com (Postfix) with ESMTP id 3DB3EE0056F for ; Fri, 18 Jan 2002 12:47:45 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id CAA16946; Sat, 19 Jan 2002 02:22:02 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201182052.CAA16946@dce.india.hp.com> To: dhcwg@ietf.org Date: Sat, 19 Jan 2002 02:22:01 +0530 (IST) Cc: vijayak@dce.india.hp.com (Vijay Bhaskar A K ) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] additional option for dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I have completed the text for the additional options which are worth adding. Please go through it and tell me your comments ~ Vijay - Network Time Protocol Server Option This option provides a list of one or more IP addresses of NTP servers available to the client. NTP Servers SHOULD be listed in order of preference. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NTP_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NTP server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NTP server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_NTP_SERVERS (TBD) option-len See section 22. NTP server IPv6 address of a NTP server available to the client. - Network Information Service (NIS) Servers Option This option provides a list of one or more IP addresses of NIS servers available to the client. NIS Servers SHOULD be listed in order of preference. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NIS_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NIS server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NIS server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_NIS_SERVERS (TBD) option-len See section 22. NIS server IPv6 address of a NIS server available to the client. - Network Information Service V2 (NIS+) Servers Option This option provides a list of one or more IP addresses of NIS+ servers available to the client. NIS+ Servers SHOULD be listed in order of preference. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NISP_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NIS+ server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NIS+ server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_NISP_SERVERS (TBD) option-len See section 22. NIS+ server IPv6 address of a NSI+ server available to the client. - FQDN Option This option specifies the name of the client. The name should be qualified with the local domain name. See [15] for character set restrictions. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FQDN | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | FQDN | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len See section 22. FQDN The FQDN of the client If there is a FQDN associated with a temporary address assigned to the IA, then this option is encapsulated inside the IA address option associated with the temporary address. It can occur as an independent option, if the FQDN denotes the host itself. - Static Route Option This option specifies a list of static routes that the client should install in its routing cache. If multiple routes to the same destination are specified, they are listed in descending order of priority. The routes consist of a list of IP address pairs. The first address is the destination address, and the second address is the router for the destination. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ROUTES | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-len | | +-+-+-+-+-+-+-+-+-+ | | | | destination prefix address (n bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | destination address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-len | | +-+-+-+-+-+-+-+-+-+ | | | | destination prefix address (n bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | router address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | option-code TBD option-len See section 22. prefix-len prefix length of the destination subnet. destination The subnet prefix of the destination subnet. prefix address Its length is byte, Where is the minimum number of bytes required to represent bits of the destination prefix address. router address The router address for reaching the destination subnet. - Subnet Selection Option This option allows the DHCP client to specify the subnet on which to allocate an address. This option takes precedence over the methods that the DHCP server uses to determine the subnet on which to select an address. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SUBNET_SELECT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-len | | +-+-+-+-+-+-+-+-+-+ | | | | subnet prefix (n bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len See section 22. prefix-len prefix length of the subnet on which the client wants the server to allocate address. subnet prefix prefix of the subnet on which the client wants the server to allocate address. Its length is byte, Where is the minimum number of bytes required to represent bits of the subnet prefix. - Network Information Service (NIS) Domain Name Option This option specifies the name of the client's NIS domain. The domain is formatted as a character string consisting of characters from the NVT-ASCII character set. The minimum length for this option is 1. See [15] for character set restrictions. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NIS_DN | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NIS Domain Name | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len See section 22. NIS Domain Name The name of the client's NIS domain. - Network Information Service V2 (NIS+) Domain Option This option specifies the name of the client's NIS+ domain. The domain is formatted as a character string consisting of characters from the NVT-ASCII character set. The minimum length for this option is 1. See [15] for character set restrictions. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NISP_DN | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NIS+ Domain Name | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len See section 22. NIS+ Domain Name The name of the client's NIS+ domain. - IEEE 1003.1 POSIX Timezone Option This option allows delivery of timezone information in the form of a IEEE 1003.1 POSIX Timezone specifier. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NISP_DN | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IEEE 1003.1 POSIX Timezone string | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len See section 22. Timezone string Timezone information in the form of a IEEE 1003.1 POSIX Timezone specifier. - Service Location Protocol Directory Agent Option The Directory Agent option specifies a one or more Directory Agents (DA), along with zero or more scopes supported by the DAs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SLP_DA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | typed-scope-list-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | SLP DA Address | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Typed Scope list | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | typed-scope-list-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | SLP DA Address | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Typed Scope list | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | option-code TBD option-len See section 22. typed-scope-list-len Length of the typed scope list. SLP DA Address IP address of the Directory Agent. Typed Scope list The string denoting the typed-scope-list formatted as per RFC 2608 and RFC 2609 - Service Location Protocol Service Scope Option This option indicates scopes that should be used by a Service Agent (SA) as described in RFC 2165, when responding to Service Request messages as specified by the Service Location Protocol (SLP). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SLP_DA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | typed-scope-list-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Typed Scope list | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | typed-scope-list-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Typed Scope list | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | option-code TBD option-len See section 22. typed-scope-list-len Length of the typed scope list. Typed Scope list specifies the scope that should be used by a Service Agent (SA) as described in RFC 2165, when responding to Service Request messages. This should be formatted as per RFC 2608 and RFC 2609 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 16:42:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28229; Fri, 18 Jan 2002 16:42:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06022; Fri, 18 Jan 2002 16:41:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05934 for ; Fri, 18 Jan 2002 16:41:46 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28195 for ; Fri, 18 Jan 2002 16:41:40 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25197; Fri, 18 Jan 2002 16:40:54 -0500 Date: Fri, 18 Jan 2002 16:40:54 -0500 (EST) From: Jim Bound To: Martin Stiemerling Cc: dhcwg@ietf.org Subject: Re: [dhcwg] static route option for dhcpv6 In-Reply-To: <8140000.1011342023@elgar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > --On Donnerstag, Januar 17, 2002 12:29:00 -0500 Jim Bound > wrote: > > > We need the static route option for the dentist office scenarios of IPv6 > > where there are two lans and no routers or as VJ pointed out ipv6forwardin > > g is turned on and not doing RAs. > > But doesn't an IPv6 router that isn't sending his router advertisements > violate the IPv6 spec? In this case DHCPv6 should not support this feature > in this way. THere are no routers in the dentist office scenario. Inn this scenario the nodes use all link-local addresses. This is also a reason why stateful IPv6 address configuration is needed ala dhcpv6. A router that does send RAs may not send necessary static routes. Like a server that sets the isarouter variable and only sends prefix RAs for configuration. I need to check the spec though thats a good point. I don't think ND mandates a router must do this. It should not IMO as it may want to let another router send RAs for routing but not addr conf. /jim > > > > > We also want it for configured tunnels and its different than DSTM. > > Ok, I agree with using it for configured tunnels. But I would choose > another name, like IPv4 Tunnel End Point. > > > > > We should also keep it simple as a config parameter. > > Yes. > > > > > I see no pain here and it is needed. Its a simple option to add and > > necessary for early IPv6 deployment as VJ pointed out in first mails. > > > > regards, > > > > > > /jim > > > > > > On Thu, 17 Jan 2002, Vijay Bhaskar A K wrote: > > > >> Please see my comments inline. > >> > >> ~Vijay. > >> > >> > After thinking about this more and after seeing the other discussion > >> > on this subject, I'm not sure exactly when or why this option would be > >> > needed. But on the other than, it technically isn't needed in IPv4 > >> > either because ICMP redirects and other routing table distribution > >> > techniques exist and DHCPv4 does have such an option (and a revised > >> > one to carry classless routes). > >> > > >> > So, we can do one of two things: > >> > 1. Include it and consider DHCPv6 as a toolbox and those people that > >> > want to use it (and those clients that want to support it) do so. For > >> > example, Solaris 8 includes the route command and it supports IPv6 > >> > routing table operations. Can anyone who has lots of experience with > >> > IPv6 deployment indicate whether there is a need to statically add > >> > routing table entries? 2. Wait until someone has a clear case of > >> > needing it and have it defined in some future document. > >> > >> Assume the following scenaria. > >> - There are 2 networks A and B. > >> - There is a node n connected to both the network, and it has enabled > >> ipv6-forwarding and not sending router advertisements. > >> > >> Now, a node in network A gets an address from the DHCPv6 server and now > >> it wants to communicate with a node in network B. In the current > >> scenario, the route has to be manually configured, then only, it will be > >> able to contact the node in network B. With static route option, we can > >> autoconfigure it. This will be more helpful in getting minimal > >> configuration for smaller networks, which don't have any router > >> advertisements and for the networks which have not completely deployed > >> routing mechanisms. > >> > >> It will be useful in the getting the configured tunnels also. > >> > >> > > >> > If we do want to include it, questions to ponder: > >> > - Should any lifetimes be associated with the routes? Either one > >> > lifetime for all routes or each route? - Should this option be > >> > encapsulated within an IA? That way, it would be renewed with the IA. > >> > >> I think, we can treat this as another configuration parameter. We don't > >> need to mix up with IA. If there are multiple IAs with same prefix, > >> then this static route is common for all these IAs. Whenever there is a > >> change in the static route, we can use reconfiguration mechanism to > >> update it. > >> > >> > > >> > I myself am leaning more towards recommending we wait until a need is > >> > found. > >> > > >> > - Bernie > >> > > >> > > >> > -----Original Message----- > >> > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > >> > Sent: Wednesday, January 16, 2002 1:13 PM > >> > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org > >> > Subject: RE: [dhcwg] static route option for dhcpv6 > >> > > >> > > >> > Bernie, > >> > This option format looks ok for me. We can include it. > >> > Vijay > >> > > >> > >> > >> -- > >> ____Vijay_Bhaskar_A_K____ > >> ______Inet_Services______ > >> ________HP_ISO___________ > >> ______Ph:_2051424________ > >> ____Telnet:_847_1424_____ > >> ___Pager:_9624_371137____ > >> > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 16:44:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28275; Fri, 18 Jan 2002 16:44:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06088; Fri, 18 Jan 2002 16:43:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06066 for ; Fri, 18 Jan 2002 16:43:40 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28255 for ; Fri, 18 Jan 2002 16:43:37 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0ILcPS12435; Fri, 18 Jan 2002 13:38:26 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0ILf9h14087; Fri, 18 Jan 2002 15:41:09 -0600 (CST) Date: Fri, 18 Jan 2002 15:41:09 -0600 Subject: Re: [dhcwg] additional option for dhcpv6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Vijay Bhaskar A K From: Ted Lemon In-Reply-To: <200201182052.CAA16946@dce.india.hp.com> Message-Id: <159A20DC-0C5C-11D6-BEE9-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I don't think we need the subnet selection option anymore. The DHCPv6 server sends relay-reply messages to the IP source address from which it received the relay-forward message, so the relay-provided prefix doesn't have to even be a valid IP address, much less one of the relay agent's IP addresses. It just has to represent a valid prefix on the link to which the client is attached, which is what the subnet selection option is. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 18 17:08:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28883; Fri, 18 Jan 2002 17:07:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07338; Fri, 18 Jan 2002 17:06:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07324 for ; Fri, 18 Jan 2002 17:06:56 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28821 for ; Fri, 18 Jan 2002 17:06:53 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA08442; Fri, 18 Jan 2002 17:06:26 -0500 (EST) Received: from MJS-PC.cisco.com (mjs-pc.cisco.com [172.27.181.69]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM51484; Fri, 18 Jan 2002 17:06:25 -0500 (EST) Message-Id: <4.3.2.7.2.20020118165044.019a0ef0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jan 2002 17:07:29 -0500 To: Vijay Bhaskar A K From: Mark Stapp Subject: Re: [dhcwg] additional option for dhcpv6 Cc: dhcwg@ietf.org In-Reply-To: <200201182052.CAA16946@dce.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Vijay, Thanks for putting this list together. I have a couple of observations. 1) The FQDN option needs, I think, to look a lot like the FQDN option for dhcpv4. The name encoding must be specified. There needs to be specification about hosts who do not initially know their entire fqdn. There needs to be a way to communicate about which party (if any) will be updating DNS. It's probably on my plate to produce that, actually. 2) The subnet-selection option text should not compel the server to somehow obey the client's suggestion. It should be explict that the server administrator's configuration takes precedence, and that the client's indication that it desires a specific subnet can only be a hint that's considered along with all of the other information available to the server. A nit: isn't the option-len sufficient to determine the prefix length? Is the prefix-len byte necessary? 3) The encoding for the domain names in the NIS and NIS+ Domain Name options should be DNS encoding, shouldn't it? That seems more robust than ASCII to me. 4) The 'Service Location Protocol Directory Agent Option' places the 'typed-scope-list-len' field before the 'DA address', rather than before the 'typed scope list'. Couldn't the length of the list immediately precede the list? -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 19 09:44:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19462; Sat, 19 Jan 2002 09:44:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08427; Sat, 19 Jan 2002 09:43:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08398 for ; Sat, 19 Jan 2002 09:43:08 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19453 for ; Sat, 19 Jan 2002 09:42:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0JEggh29018 for ; Sat, 19 Jan 2002 08:42:42 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0JEggf21532 for ; Sat, 19 Jan 2002 08:42:42 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sat Jan 19 08:42:41 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 19 Jan 2002 08:42:41 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC1@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Vijay Bhaskar A K'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Sat, 19 Jan 2002 08:42:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A0F7.8C4FF0A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A0F7.8C4FF0A0 Content-Type: text/plain; charset="iso-8859-1" Vijay: I've cut out much of the text to avoid the delays due to the size of the messages. See my comments as BV3. > BV2> Again, all the server does is use the address to determine the LINK. > So, the server needs to know about the site local prefix being active on > the link but that's all. If the server fails to find the prefix for the > address, it can either drop the request or it could simply assume it must > have come from the LINKs associated with the interface the packet was > received on. So, it is happy. > > Note that the client really should be using the link local address UNLESS > it is unicasting to a server (in which case it must use an address of > sufficient scope valid for the server to send replies). The All DHCP > Agents address is link scoped, so the source address only needs to be > linked scoped as well. > > So, I don't see any issues here. Or am I failing to understand your concern? VB2> What i mean is, for finding the link, server should not trust client. It knows the link where it is received. Based on its own address in the link, it should allocate address to the client. The client may not be knowing where it is. Sometimes, what it has may be wrong. So, the src address in IP datagram may show wrong information. VB2> Assume, a client is moving from the 3ffe::/64 network to 5ffe::/64 network. As per the draft, it will the confirm message. 16.2.2 says that, the server will just compare the binding info it's having with the one in confirm message. I think the server MUST check the prefix also. It must check whether the addresses in the IA are having the same prefixes of the link in which the client is connected to. I think, no where in the draft, the draft is not dealing with the prefix comparison of the link and IA addresses. So, in this case, the server sends a positive reply. The client wont get it, because, it does have a valid address to receive it. VB2> After some time, if it requires another address, it will send a new request with the src address with 3ffe::/64 prefix and hence the server allocates the address with 3ffe::/64 prefix for the 5ffe::/64 network. I think the neat and clean way of client asking for the addresses in a particular prefix, is sending through an option, similar to subnet selection option (RFC 3011). I can include the text for this option. This is one of the option, i have forgetten to tell in the previous mail. ---- BV3> You are forgetting ONE case ... what if the client was allowed to unicast to the server. In that case, we really do need to use the address supplied by the client as that is the only way the server can determine were the client is. And you are not considering the rules for the source address that the client is supposed to be using. So, if we assume clients are playing by the rules (which they MUST IMHO), you have the following possibilities: 1) The client is communicating via a relay agent. In that case things are easy since the server receives a Reply-Forw. 2) The client is on the local link (and NOT unicasting), in that case the client's address MUST be the link-local address and the server uses the interface on which the request was received. 3) The client is UNICASTING because the server has allowed it to do so. In that case, the server MUST use the client's source address to determine the address. The client MUST also use a source address that is of sufficient scope to reach the server. Ideally, this should be a global address as that avoids any issues with the client moving to a new link (since global addresses are "valid" anywhere). In this case you also don't have any problems because if the client has moved to a new link, it should be sending a CONFIRM which is *NOT* unicast. So, I don't see why there are any cases where there are problems if the client follows the rules I've outlined above (which I believe was our intent). I've already indicated that we should clean up the language in the draft that says a client MUST use the link-local unless it is UNICASTING to a server. BTW, I haven't checked the source address selection draft out lately, but it was my understanding that if a sender is sending to a link-local address (such as the All DHCP Agents Multicast) that it should also use a link-local address as the source address (since there is no reason not to). - Bernie Volz ------_=_NextPart_001_01C1A0F7.8C4FF0A0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Comments on 22 rev of the draft

Vijay:

I've cut out much of the text to avoid the delays due to the size of the messages.

See my comments as BV3.

> BV2> Again, all the server does is use the address to determine the LINK.
> So, the server needs to know about the site local prefix being active on
> the link but that's all. If the server fails to find the prefix for the
> address, it can either drop the request or it could simply assume it must
> have come from the LINKs associated with the interface the packet was
> received on. So, it is happy.
>
> Note that the client really should be using the link local address UNLESS
> it is unicasting to a server (in which case it must use an address of
> sufficient scope valid for the server to send replies). The All DHCP
> Agents address is link scoped, so the source address only needs to be
> linked scoped as well.
>
> So, I don't see any issues here. Or am I failing to understand your concern?

VB2> What i mean is, for  finding  the  link,  server  should  not trust
client.  It  knows  the  link  where it is  received.  Based  on its own
address  in the link, it should  allocate  address  to the  client.  The
client may not be  knowing  where it is.  Sometimes,  what it has may be
wrong.  So, the src address in IP datagram may show wrong information.

VB2> Assume,  a client is moving from the 3ffe::/64 network to 5ffe::/64
network.  As per the draft, it will the  confirm  message.  16.2.2  says
that, the server will just compare the binding info it's having with the
one in confirm  message.  I think the server MUST check the prefix also.
It must  check  whether  the  addresses  in the IA are  having  the same
prefixes of the link in which the client is  connected  to.  I think, no
where in the draft, the draft is not dealing with the prefix  comparison
of the link and IA  addresses.  So, in this  case,  the  server  sends a
positive  reply.  The client wont get it,  because, it does have a valid
address to receive it.

VB2> After some time, if it requires another address, it will send a new
request with the src address with 3ffe::/64  prefix and hence the server
allocates the address with 3ffe::/64  prefix for the 5ffe::/64  network.
I think the neat and clean way of client  asking for the  addresses in a
particular  prefix,  is sending  through  an option,  similar  to subnet
selection  option  (RFC 3011).  I can include the text for this  option.
This is one of the  option,  i have  forgetten  to tell in the  previous
mail.

----

BV3> You are forgetting ONE case ... what if the client was allowed to
unicast to the server. In that case, we really do need to use the address
supplied by the client as that is the only way the server can determine
were the client is.

And you are not considering the rules for the source address that the
client is supposed to be using. So, if we assume clients are playing by
the rules (which they MUST IMHO), you have the following possibilities:
1) The client is communicating via a relay agent. In that case things are
easy since the server receives a Reply-Forw.
2) The client is on the local link (and NOT unicasting), in that case
the client's address MUST be the link-local address and the server uses
the interface on which the request was received.
3) The client is UNICASTING because the server has allowed it to do so.
In that case, the server MUST use the client's source address to determine
the address. The client MUST also use a source address that is of sufficient
scope to reach the server. Ideally, this should be a global address as that
avoids any issues with the client moving to a new link (since global addresses
are "valid" anywhere). In this case you also don't have any problems because
if the client has moved to a new link, it should be sending a CONFIRM which
is *NOT* unicast.

So, I don't see why there are any cases where there are problems if the
client follows the rules I've outlined above (which I believe was our intent).

I've already indicated that we should clean up the language in the draft
that says a client MUST use the link-local unless it is UNICASTING to a server.

BTW, I haven't checked the source address selection draft out lately, but it
was my understanding that if a sender is sending to a link-local address (such
as the All DHCP Agents Multicast) that it should also use a link-local address
as the source address (since there is no reason not to).

- Bernie Volz

------_=_NextPart_001_01C1A0F7.8C4FF0A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 19 09:54:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19562; Sat, 19 Jan 2002 09:54:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08536; Sat, 19 Jan 2002 09:53:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08511 for ; Sat, 19 Jan 2002 09:53:53 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19559 for ; Sat, 19 Jan 2002 09:53:50 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0JErNS28519 for ; Sat, 19 Jan 2002 08:53:23 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0JErNf22526 for ; Sat, 19 Jan 2002 08:53:23 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sat Jan 19 08:53:22 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 19 Jan 2002 08:53:22 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC3@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Mark Stapp'" , Vijay Bhaskar A K Cc: dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 Date: Sat, 19 Jan 2002 08:53:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A0F9.097BE560" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A0F9.097BE560 Content-Type: text/plain; charset="iso-8859-1" I haven't looked in detail at Vijay's option definitions, but all domain names should be encoded using Section 10 (Representation and use of domain names). So, this may remove the need to have a bit in the FQDN option to specify the encoding! This applies to issues 1 and 3 below. - Bernie -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Friday, January 18, 2002 5:07 PM To: Vijay Bhaskar A K Cc: dhcwg@ietf.org Subject: Re: [dhcwg] additional option for dhcpv6 Vijay, Thanks for putting this list together. I have a couple of observations. 1) The FQDN option needs, I think, to look a lot like the FQDN option for dhcpv4. The name encoding must be specified. There needs to be specification about hosts who do not initially know their entire fqdn. There needs to be a way to communicate about which party (if any) will be updating DNS. It's probably on my plate to produce that, actually. 2) The subnet-selection option text should not compel the server to somehow obey the client's suggestion. It should be explict that the server administrator's configuration takes precedence, and that the client's indication that it desires a specific subnet can only be a hint that's considered along with all of the other information available to the server. A nit: isn't the option-len sufficient to determine the prefix length? Is the prefix-len byte necessary? 3) The encoding for the domain names in the NIS and NIS+ Domain Name options should be DNS encoding, shouldn't it? That seems more robust than ASCII to me. 4) The 'Service Location Protocol Directory Agent Option' places the 'typed-scope-list-len' field before the 'DA address', rather than before the 'typed scope list'. Couldn't the length of the list immediately precede the list? -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A0F9.097BE560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional option for dhcpv6

I haven't looked in detail at Vijay's option = definitions, but all domain names
should be encoded using Section 10 (Representation = and use of domain names). So,
this may remove the need to have a bit in the FQDN = option to specify the encoding!
This applies to issues 1 and 3 below.

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Friday, January 18, 2002 5:07 PM
To: Vijay Bhaskar A K
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] additional option for = dhcpv6


Vijay,
Thanks for putting this list together. I have a = couple of observations.

1) The FQDN option needs, I think, to look a lot like = the FQDN option for
dhcpv4. The name encoding must be specified. There = needs to be
specification about hosts who do not initially know = their entire fqdn.
There needs to be a way to communicate about which = party (if any) will be
updating DNS. It's probably on my plate to produce = that, actually.

2) The subnet-selection option text should not compel = the server to somehow
obey the client's suggestion. It should be explict = that the server
administrator's configuration takes precedence, and = that the client's
indication that it desires a specific subnet can = only be a hint that's
considered along with all of the other information = available to the server.

A nit: isn't the option-len sufficient to determine = the prefix length? Is
the prefix-len byte necessary?

3) The encoding for the domain names in the NIS and = NIS+ Domain Name
options should be DNS encoding, shouldn't it? That = seems more robust than
ASCII to me.

4) The 'Service Location Protocol Directory Agent = Option' places the
'typed-scope-list-len' field before the 'DA = address', rather than before
the 'typed scope list'. Couldn't the length of the = list immediately precede
the list?

-- Mark


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A0F9.097BE560-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 19 15:01:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22392; Sat, 19 Jan 2002 15:01:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16051; Sat, 19 Jan 2002 15:00:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16012 for ; Sat, 19 Jan 2002 15:00:11 -0500 (EST) Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22378 for ; Sat, 19 Jan 2002 15:00:07 -0500 (EST) Received: (qmail 4561 invoked by uid 511); 19 Jan 2002 19:59:38 -0000 Message-ID: <20020119195938.4560.qmail@quiet-like-a-panther.org> From: Michael Johnston To: "dhcwg" Date: Sat, 19 Jan 2002 19:59:38 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Gentles, For the DUID contents definition (Section 11): Would you be adverse to expanding the size of the VUID to 128 bits or creating an additional type (4) for a 128 bit UUID? Reasoning: According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT change over time...". From what I have seen, most new laptops, desktops & workstations (especially those that come with network installed) already contain, or have space reserved for, a 128 bit UUID that is intended to be used to manage/track the system identity. Why have a vendor or IT assign yet another ID number to the system. Using the link-layer address is also not a unique solution. Consider the two cases of (1) laptops connecting to docking stations that contain network adapters and (2) replacing defective or upgrading to new network adapters. %%michael _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 19 19:08:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24040; Sat, 19 Jan 2002 19:08:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21235; Sat, 19 Jan 2002 19:07:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21212 for ; Sat, 19 Jan 2002 19:07:14 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24028 for ; Sat, 19 Jan 2002 19:07:07 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0K06cS10254 for ; Sat, 19 Jan 2002 18:06:38 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0K06cf20738 for ; Sat, 19 Jan 2002 18:06:38 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sat Jan 19 18:06:37 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 19 Jan 2002 18:06:37 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC5@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Michael Johnston'" , dhcwg Subject: RE: [dhcwg] dhcpv6-22 DUID/VUID questions/comments Date: Sat, 19 Jan 2002 18:06:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A146.54313C20" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A146.54313C20 Content-Type: text/plain; charset="iso-8859-1" Hi: If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). Do you or does anyone else have some good information about the what new systems are using for UUIDs? - Bernie Volz -----Original Message----- From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] Sent: Saturday, January 19, 2002 3:00 PM To: dhcwg Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments Gentles, For the DUID contents definition (Section 11): Would you be adverse to expanding the size of the VUID to 128 bits or creating an additional type (4) for a 128 bit UUID? Reasoning: According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT change over time...". From what I have seen, most new laptops, desktops & workstations (especially those that come with network installed) already contain, or have space reserved for, a 128 bit UUID that is intended to be used to manage/track the system identity. Why have a vendor or IT assign yet another ID number to the system. Using the link-layer address is also not a unique solution. Consider the two cases of (1) laptops connecting to docking stations that contain network adapters and (2) replacing defective or upgrading to new network adapters. %%michael _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A146.54313C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-22 DUID/VUID questions/comments

Hi:

If there is good evidence that a 128-bit identifier = makes much more sense than using the 64-bit identifier currently = defined for type 2 (section 11.3), perhaps we should just use the = 128-bits (a vendor that only has 64-bit identifier, could simply use = 0's in the rest of the bits).

Do you or does anyone else have some good information = about the what new systems are using for UUIDs?

- Bernie Volz

-----Original Message-----
From: Michael Johnston [mailto:frenchy@quiet-li= ke-a-panther.org]
Sent: Saturday, January 19, 2002 3:00 PM
To: dhcwg
Subject: [dhcwg] dhcpv6-22 DUID/VUID = questions/comments


Gentles,

For the DUID contents definition (Section 11): =

Would you be adverse to expanding the size of the = VUID to 128 bits or
creating an additional type (4) for a 128 bit UUID? =

Reasoning:

According to the dhcpv6-22 draft, "... the DUID = used by a client SHOULD NOT
change over time...".  From what I have = seen, most new laptops, desktops &
workstations (especially those that come with = network installed) already
contain, or have space reserved for, a 128 bit UUID = that is intended to be
used to manage/track the system identity.  Why = have a vendor or IT assign
yet another ID number to the system.

Using the link-layer address is also not a unique = solution.  Consider the
two cases of (1) laptops connecting to docking = stations that contain network
adapters and (2) replacing defective or upgrading to = new network adapters.


%%michael

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A146.54313C20-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 19 21:43:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26072; Sat, 19 Jan 2002 21:43:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24440; Sat, 19 Jan 2002 21:42:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24420 for ; Sat, 19 Jan 2002 21:42:51 -0500 (EST) Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26056 for ; Sat, 19 Jan 2002 21:42:46 -0500 (EST) Received: (qmail 5919 invoked by uid 511); 20 Jan 2002 02:42:18 -0000 Message-ID: <20020120024218.5918.qmail@quiet-like-a-panther.org> References: <66F66129A77AD411B76200508B65AC69B4CDC5@EAMBUNT705> In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC5@EAMBUNT705> From: Michael Johnston To: "Bernie Volz \(EUD\)" Cc: dhcwg Date: Sun, 20 Jan 2002 02:42:18 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Bernie, Intel-ish systems are what I use the most, so my information is skewed in that direction. The UUIDs being used today are derived from the algorithm in this document: http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt Mechanisms for retrieving (and in many cases storing) the platform UUID from (to) non-volatile storage are included in (or with) most x86PC compatible laptop and desktop systems and all Intel Itanium workstations and servers. In order to get Microsoft WHQL or Intel WfM certification all systems with network boot support must contain or generate a valid platform UUID. EFI (Extensible Firmware Interface) also requires a platform UUID. %%michael Bernie Volz (EUD) writes: > Hi: > > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). > > Do you or does anyone else have some good information about the what new systems are using for UUIDs? > > - Bernie Volz > > -----Original Message----- > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] > Sent: Saturday, January 19, 2002 3:00 PM > To: dhcwg > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments > > > Gentles, > > For the DUID contents definition (Section 11): > > Would you be adverse to expanding the size of the VUID to 128 bits or > creating an additional type (4) for a 128 bit UUID? > > Reasoning: > > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT > change over time...". From what I have seen, most new laptops, desktops & > workstations (especially those that come with network installed) already > contain, or have space reserved for, a 128 bit UUID that is intended to be > used to manage/track the system identity. Why have a vendor or IT assign > yet another ID number to the system. > > Using the link-layer address is also not a unique solution. Consider the > two cases of (1) laptops connecting to docking stations that contain network > adapters and (2) replacing defective or upgrading to new network adapters. > > > %%michael > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 09:31:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10887; Sun, 20 Jan 2002 09:31:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17965; Sun, 20 Jan 2002 09:30:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17936 for ; Sun, 20 Jan 2002 09:30:46 -0500 (EST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10868 for ; Sun, 20 Jan 2002 09:30:38 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel12.hp.com (Postfix) with ESMTP id 6D112E00CAD; Sun, 20 Jan 2002 06:30:06 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id UAA22474; Sun, 20 Jan 2002 20:04:24 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201201434.UAA22474@dce.india.hp.com> Subject: Re: [dhcwg] additional option for dhcpv6 To: mjs@cisco.com Date: Sun, 20 Jan 2002 20:04:24 +0530 (IST) Cc: vijayak@india.hp.com, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020118165044.019a0ef0@goblet.cisco.com> from Mark Stapp at Jan "18," 2002 "05:07:29" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Mark, Thanks for your thorough review. See my comments inline. ~ Vijay > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > dhcpv4. The option i defined here is, for just transfering the FQDN releated to temporary address. It is similar to hostname option in DHCPv4. I will rename it to hostname option. I feel like, since the DDNS updates are still TBD, we can define the FQDN option with appropriate fields needed later, once DDNS specs are finalised. > The name encoding must be specified. Yes. It is needed. I will add the appropriate text. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. For the temporary addresses, DNS update is done by server. So, these fields are not necessary. > > 2) The subnet-selection option text should not compel the server to somehow > obey the client's suggestion. It should be explict that the server > administrator's configuration takes precedence, and that the client's > indication that it desires a specific subnet can only be a hint that's > considered along with all of the other information available to the server. This is the only way the client can tell its prefernce for the prefix. If the server is not supposed to allocate address for that prefix, then it wont. If the client is not very particular about the prefix, it should not use this option. This option will be more helpful in the network with two prefixes and the client wants a particular one. > > A nit: isn't the option-len sufficient to determine the prefix length? Is > the prefix-len byte necessary? No, it is not sufficient. Without the prefix-len field, you cannot find out the exact prefix length. For example, you can identify whether the prefix length is between 57 and 64. You cannot find out the exact prefix length. > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > options should be DNS encoding, shouldn't it? That seems more robust than > ASCII to me. Agreed. > > 4) The 'Service Location Protocol Directory Agent Option' places the > 'typed-scope-list-len' field before the 'DA address', rather than before > the 'typed scope list'. Couldn't the length of the list immediately precede > the list? I think, it won't make any difference. Let me know, if there are any serious issues on this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 12:52:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14113; Sun, 20 Jan 2002 12:52:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22439; Sun, 20 Jan 2002 12:51:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22417 for ; Sun, 20 Jan 2002 12:51:39 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14106 for ; Sun, 20 Jan 2002 12:51:36 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01480; Sun, 20 Jan 2002 12:51:34 -0500 Date: Sun, 20 Jan 2002 12:51:33 -0500 (EST) From: Jim Bound To: Michael Johnston Cc: "Bernie Volz (EUD)" , dhcwg Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments In-Reply-To: <20020120024218.5918.qmail@quiet-like-a-panther.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Infiniband spec uses 128 bit global UIDs too. I think it makes sense to have a 128bit option but keep the 64bit too. If we can just add it as another option which I think we can. But we don't want to hold up the spec either. /jim On Sun, 20 Jan 2002, Michael Johnston wrote: > Bernie, > > Intel-ish systems are what I use the most, so my information is skewed in > that direction. > > The UUIDs being used today are derived from the algorithm in this document: > http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt > > Mechanisms for retrieving (and in many cases storing) the platform UUID from > (to) non-volatile storage are included in (or with) most x86PC compatible > laptop and desktop systems and all Intel Itanium workstations and servers. > > In order to get Microsoft WHQL or Intel WfM certification all systems with > network boot support must contain or generate a valid platform UUID. > > EFI (Extensible Firmware Interface) also requires a platform UUID. > > > %%michael > > > Bernie Volz (EUD) writes: > > > Hi: > > > > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). > > > > Do you or does anyone else have some good information about the what new systems are using for UUIDs? > > > > - Bernie Volz > > > > -----Original Message----- > > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] > > Sent: Saturday, January 19, 2002 3:00 PM > > To: dhcwg > > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments > > > > > > Gentles, > > > > For the DUID contents definition (Section 11): > > > > Would you be adverse to expanding the size of the VUID to 128 bits or > > creating an additional type (4) for a 128 bit UUID? > > > > Reasoning: > > > > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT > > change over time...". From what I have seen, most new laptops, desktops & > > workstations (especially those that come with network installed) already > > contain, or have space reserved for, a 128 bit UUID that is intended to be > > used to manage/track the system identity. Why have a vendor or IT assign > > yet another ID number to the system. > > > > Using the link-layer address is also not a unique solution. Consider the > > two cases of (1) laptops connecting to docking stations that contain network > > adapters and (2) replacing defective or upgrading to new network adapters. > > > > > > %%michael > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 12:57:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14197; Sun, 20 Jan 2002 12:57:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22515; Sun, 20 Jan 2002 12:57:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22488 for ; Sun, 20 Jan 2002 12:57:35 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14184 for ; Sun, 20 Jan 2002 12:57:08 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0KHvAh28089 for ; Sun, 20 Jan 2002 11:57:10 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0KHvAf25169 for ; Sun, 20 Jan 2002 11:57:10 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Jan 20 11:57:10 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jan 2002 11:57:10 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC6@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Vijay Bhaskar A K'" , mjs@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 Date: Sun, 20 Jan 2002 11:57:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A1DB.E0B65500" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A1DB.E0B65500 Content-Type: text/plain; charset="iso-8859-1" Vijay: I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: - a 16-bit option number/option length - "A" RRs replaced by "AAAA" RRs. - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Sunday, January 20, 2002 9:34 AM To: mjs@cisco.com Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: [dhcwg] additional option for dhcpv6 Mark, Thanks for your thorough review. See my comments inline. ~ Vijay > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > dhcpv4. The option i defined here is, for just transfering the FQDN releated to temporary address. It is similar to hostname option in DHCPv4. I will rename it to hostname option. I feel like, since the DDNS updates are still TBD, we can define the FQDN option with appropriate fields needed later, once DDNS specs are finalised. > The name encoding must be specified. Yes. It is needed. I will add the appropriate text. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. For the temporary addresses, DNS update is done by server. So, these fields are not necessary. > > 2) The subnet-selection option text should not compel the server to somehow > obey the client's suggestion. It should be explict that the server > administrator's configuration takes precedence, and that the client's > indication that it desires a specific subnet can only be a hint that's > considered along with all of the other information available to the server. This is the only way the client can tell its prefernce for the prefix. If the server is not supposed to allocate address for that prefix, then it wont. If the client is not very particular about the prefix, it should not use this option. This option will be more helpful in the network with two prefixes and the client wants a particular one. > > A nit: isn't the option-len sufficient to determine the prefix length? Is > the prefix-len byte necessary? No, it is not sufficient. Without the prefix-len field, you cannot find out the exact prefix length. For example, you can identify whether the prefix length is between 57 and 64. You cannot find out the exact prefix length. > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > options should be DNS encoding, shouldn't it? That seems more robust than > ASCII to me. Agreed. > > 4) The 'Service Location Protocol Directory Agent Option' places the > 'typed-scope-list-len' field before the 'DA address', rather than before > the 'typed scope list'. Couldn't the length of the list immediately precede > the list? I think, it won't make any difference. Let me know, if there are any serious issues on this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A1DB.E0B65500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional option for dhcpv6

Vijay:

I don't understand your desire to do DDNS updates for = temporary addresses. We specifically do NOT want to do them. The -22 = draft just says that if a server does DDNS updates, it must follow the = rules of RFC 3041.

I think you have things backwards a bit. = Non-temporary addresses are the addresses that need domain names = (FQDNs) assoicated with them. Temporary addresses really shouldn't = since that defeats the purpose of temporary addresses. However, what = RFC 3041 says, is that if DDNS updates are done, the name should be = something that doesn't identify the client. It gives one reason for = doing this and that is to keep applications happy that = "authenticate" clients by doing a reverse and then forward = lookup to assure the client is in DNS.

We need a general FQDN option. Where it is placed = (encapulated within the option area of an IA Address option, inside the = option area of an IA option, or outside IA options) determines its = scope (to one address, several addresses, or all addresses). For = temporary addresses, the scope should be to that one address (since = even using the same name with two temporary addresses could leak = information about the client).

So, I see no value in an option that is just for = temporary addresses. We should define a FQDN option and use it whenever = DDNS updates are done. The format should be defined as in = draft-ietf-dhc-fqdn-option-03.txt with the following = differences:

- a 16-bit option number/option length
- "A" RRs replaced by "AAAA" = RRs.
- Name encoding should be as per section 10 of the = -22 draft on DNS encodings (hence we technically don't need the = "E" bit in the flag field but I would recommend we simply = specify it MUST always be set to allow common code to be used on the = client and/or server).

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Sunday, January 20, 2002 9:34 AM
To: mjs@cisco.com
Cc: vijayak@india.hp.com; dhcwg@ietf.org
Subject: Re: [dhcwg] additional option for = dhcpv6


Mark,

Thanks for your thorough review. See my comments = inline.

~ Vijay

> 1) The FQDN option needs, I think, to look a lot = like the FQDN option for
> dhcpv4.

The option i defined here is, for just  = transfering the FQDN releated to
temporary  address.  It is  = similar  to  hostname  option in  DHCPv4.  = I
will rename it to hostname  option.  I = feel like, since the DDNS updates
are still TBD, we can define the FQDN  = option  with  appropriate  fields
needed later, once DDNS specs are finalised.

> The name encoding must be specified.

Yes. It is needed. I will add the appropriate = text.

> There needs to be
> specification about hosts who do not initially = know their entire fqdn.
> There needs to be a way to communicate about = which party (if any) will be
> updating DNS. It's probably on my plate to = produce that, actually.

For the  temporary  addresses,  DNS = update is done by server.  So, these
fields are not necessary.

>
> 2) The subnet-selection option text should not = compel the server to somehow
> obey the client's suggestion. It should be = explict that the server
> administrator's configuration takes precedence, = and that the client's
> indication that it desires a specific subnet = can only be a hint that's
> considered along with all of the other = information available to the server.

This is the only way the client can tell its  = prefernce  for the prefix.
If the server is not supposed to allocate  = address for that prefix, then
it wont.  If the  client is not very  = particular  about the  prefix,  it
should not use this  option.  This  = option  will be more  helpful in the
network with two prefixes and the client wants a = particular one.

>
> A nit: isn't the option-len sufficient to = determine the prefix length? Is
> the prefix-len byte necessary?

No, it is not sufficient.  Without the = prefix-len field, you cannot find
out the exact prefix length.  For example, you = can identify  whether the
prefix  length  is  between  57 = and 64.  You  cannot  find out the exact
prefix length.

>
> 3) The encoding for the domain names in the NIS = and NIS+ Domain Name
> options should be DNS encoding, shouldn't it? = That seems more robust than
> ASCII to me.

Agreed.

>
> 4) The 'Service Location Protocol Directory = Agent Option' places the
> 'typed-scope-list-len' field before the 'DA = address', rather than before
> the 'typed scope list'. Couldn't the length of = the list immediately precede
> the list?

I think,  it won't  make any  = difference.  Let me  know, if there are any
serious issues on this.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A1DB.E0B65500-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 13:03:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14329; Sun, 20 Jan 2002 13:03:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23056; Sun, 20 Jan 2002 13:03:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22985 for ; Sun, 20 Jan 2002 13:03:09 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14324 for ; Sun, 20 Jan 2002 13:03:05 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0KI37h28717 for ; Sun, 20 Jan 2002 12:03:07 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0KI37f25773 for ; Sun, 20 Jan 2002 12:03:07 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Jan 20 12:03:06 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jan 2002 12:03:06 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" , Michael Johnston Cc: dhcwg Subject: RE: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments Date: Sun, 20 Jan 2002 12:03:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A1DC.B4A4F0B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A1DC.B4A4F0B0 Content-Type: text/plain; charset="iso-8859-1" What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway. So, in 11.3 we could change it to be: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VUID length (in bits) | VUID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . VUID (variable length) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . domain name (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VUID length is the number of bits of the VUID. VUID is the VUID (of (VUID length + 7)/8 bytes). - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Sunday, January 20, 2002 12:52 PM To: Michael Johnston Cc: Bernie Volz (EUD); dhcwg Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments Infiniband spec uses 128 bit global UIDs too. I think it makes sense to have a 128bit option but keep the 64bit too. If we can just add it as another option which I think we can. But we don't want to hold up the spec either. /jim On Sun, 20 Jan 2002, Michael Johnston wrote: > Bernie, > > Intel-ish systems are what I use the most, so my information is skewed in > that direction. > > The UUIDs being used today are derived from the algorithm in this document: > http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt > > Mechanisms for retrieving (and in many cases storing) the platform UUID from > (to) non-volatile storage are included in (or with) most x86PC compatible > laptop and desktop systems and all Intel Itanium workstations and servers. > > In order to get Microsoft WHQL or Intel WfM certification all systems with > network boot support must contain or generate a valid platform UUID. > > EFI (Extensible Firmware Interface) also requires a platform UUID. > > > %%michael > > > Bernie Volz (EUD) writes: > > > Hi: > > > > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). > > > > Do you or does anyone else have some good information about the what new systems are using for UUIDs? > > > > - Bernie Volz > > > > -----Original Message----- > > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] > > Sent: Saturday, January 19, 2002 3:00 PM > > To: dhcwg > > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments > > > > > > Gentles, > > > > For the DUID contents definition (Section 11): > > > > Would you be adverse to expanding the size of the VUID to 128 bits or > > creating an additional type (4) for a 128 bit UUID? > > > > Reasoning: > > > > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT > > change over time...". From what I have seen, most new laptops, desktops & > > workstations (especially those that come with network installed) already > > contain, or have space reserved for, a 128 bit UUID that is intended to be > > used to manage/track the system identity. Why have a vendor or IT assign > > yet another ID number to the system. > > > > Using the link-layer address is also not a unique solution. Consider the > > two cases of (1) laptops connecting to docking stations that contain network > > adapters and (2) replacing defective or upgrading to new network adapters. > > > > > > %%michael > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1A1DC.B4A4F0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments

What about considering a variable length field for = this type and adding a 16-bit length to allow the length to be = specified? That way, a vendor can use what they like. The server treats = it as opaque anyway.

So, in 11.3 we could change it to be:

    = 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
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   |       = VUID length (in bits)   |     VUID = (variable length)    |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = .           &nbs= p;        VUID (variable = length)           = ;          |
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = .           &nbs= p;      domain name (variable = length)           = ;     .
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

VUID length is the number of bits of the VUID.

VUID is the VUID (of (VUID length + 7)/8 = bytes).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Sunday, January 20, 2002 12:52 PM
To: Michael Johnston
Cc: Bernie Volz (EUD); dhcwg
Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID = questions/comments


Infiniband spec uses 128 bit global UIDs too.  I = think it makes sense to
have a 128bit option but keep the 64bit = too.   If we can just add it as
another option which I think we can.  But we = don't want to hold up the
spec either.


/jim


On Sun, 20 Jan 2002, Michael Johnston wrote:

> Bernie,
>
> Intel-ish systems are what I use the most, so = my information is skewed in
> that direction.
>
> The UUIDs being used today are derived from the = algorithm in this document:
> http://www.opengroup.org/dce/info/draft-leach-uuids-gu= ids-01.txt
>
> Mechanisms for retrieving (and in many cases = storing) the platform UUID from
> (to) non-volatile storage are included in (or = with) most x86PC compatible
> laptop and desktop systems and all Intel = Itanium workstations and servers.
>
> In order to get Microsoft WHQL or Intel WfM = certification all systems with
> network boot support must contain or generate a = valid platform UUID.
>
> EFI (Extensible Firmware Interface) also = requires a platform UUID.
>
>
> %%michael
>
>
> Bernie Volz (EUD) writes:
>
> > Hi:
> >
> > If there is good evidence that a 128-bit = identifier makes much more sense than using the 64-bit identifier = currently defined for type 2 (section 11.3), perhaps we should just use = the 128-bits (a vendor that only has 64-bit identifier, could simply = use 0's in the rest of the bits).

> >
> > Do you or does anyone else have some good = information about the what new systems are using for UUIDs?
> >
> > - Bernie Volz
> >
> > -----Original Message-----
> > From: Michael Johnston [mailto:frenchy@quiet-li= ke-a-panther.org]
> > Sent: Saturday, January 19, 2002 3:00 = PM
> > To: dhcwg
> > Subject: [dhcwg] dhcpv6-22 DUID/VUID = questions/comments
> >
> >
> > Gentles,
> >
> > For the DUID contents definition (Section = 11): 
> >
> > Would you be adverse to expanding the size = of the VUID to 128 bits or
> > creating an additional type (4) for a 128 = bit UUID? 
> >
> > Reasoning: 
> >
> > According to the dhcpv6-22 draft, = "... the DUID used by a client SHOULD NOT
> > change over time...".  From what = I have seen, most new laptops, desktops &
> > workstations (especially those that come = with network installed) already
> > contain, or have space reserved for, a 128 = bit UUID that is intended to be
> > used to manage/track the system = identity.  Why have a vendor or IT assign
> > yet another ID number to the system.  =
> >
> > Using the link-layer address is also not a = unique solution.  Consider the
> > two cases of (1) laptops connecting to = docking stations that contain network
> > adapters and (2) replacing defective or = upgrading to new network adapters. 
> >
> >
> > %%michael 
> >
> > = _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> 
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1A1DC.B4A4F0B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 13:14:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14497; Sun, 20 Jan 2002 13:14:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23262; Sun, 20 Jan 2002 13:14:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23235 for ; Sun, 20 Jan 2002 13:14:32 -0500 (EST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14471 for ; Sun, 20 Jan 2002 13:14:28 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel13.hp.com (Postfix) with ESMTP id 699D5E00AAF; Sun, 20 Jan 2002 10:13:58 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id XAA22645; Sun, 20 Jan 2002 23:39:40 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" Cc: , Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Sun, 20 Jan 2002 23:44:57 +0530 Message-ID: <000401c1a1de$5e64cac0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1A20C.781D06C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC1@EAMBUNT705> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1A20C.781D06C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: [dhcwg] Comments on 22 rev of the draftHi Bernie, See my reply inline prefixed by VB3> BV3> You are forgetting ONE case ... what if the client was allowed to unicast to the server. In that case, we really do need to use the address supplied by the client as that is the only way the server can determine were the client is. VB3> This is where the problem arises. If the client network has two prefixes, 3ffe::/64 and 5ffe::/64 and the client wants the address with 3ffe::/64 prefix, it has not the flexibility of choosing the source address. The source address selection algorithm may choose any address. It is based on the destination address. If the destination address (server addr) is 5ffe::/64, then the source address selection chooses the source address from 5ffe::/64 only. So, the subnet selection option is the only way of indicating the client's wish of the prefix. And you are not considering the rules for the source address that the client is supposed to be using. So, if we assume clients are playing by the rules (which they MUST IMHO), you have the following possibilities: 1) The client is communicating via a relay agent. In that case things are easy since the server receives a Reply-Forw. 2) The client is on the local link (and NOT unicasting), in that case the client's address MUST be the link-local address and the server uses the interface on which the request was received. 3) The client is UNICASTING because the server has allowed it to do so. In that case, the server MUST use the client's source address to determine the address. The client MUST also use a source address that is of sufficient scope to reach the server. Ideally, this should be a global address as that avoids any issues with the client moving to a new link (since global addresses are "valid" anywhere). VB3> I am sure that global address is unique over the world, but i am not sure, whether it is valid anywhere. I am not sure, whether the host with subnet preifx 3ffe::/64 moved to 5ffe::/64, will be able to receive the packet with destined to its 3ffe::/64 address. In this case you also don't have any problems because if the client has moved to a new link, it should be sending a CONFIRM which is *NOT* unicast. VB3> Regarding the confirm, i have few doubts. - draft says that, when the client moves to new link, it has to send confirm message. How can the host identify it has moved to a new network? Are we taking care of ICMP error messages? - Link local address is unique within the link. When a node is moved from one link to another one, we cannot surely say that the link local address is unique. What will happen, the link local address of the interface is used by some other node in that link? - since, this address is the one, which has to be used as source address for confirm, does the client has to do a ND first for confirming uniqueness within the link? VB3> As i told earlier, a text has to be added for checking whether the addresses in the IA has the same prefix as that of the link it resides, when confirm message is received in the server. Otherwise, the confirm will get a positive reply from the server, resulting in defeat of the purpose of confirm. VB3> Here, i have another doubt. Assume the following scenario. Assume the Relay agent has addresses from two prefix A and B in the link attached to the client. Client has some addresses of prefix A. It has been rebooted now. So, it sends the confirm packet. The confirm is received in the relay agent's interface. Now, what prefix it has to put in the link-address field. If it chooses to put B, then the addresses assigned to client becomes invalid. In what basis, the Relay agent chooses the prefixes, if the interface attached to the client's link has more than one prefixes? ------=_NextPart_000_0005_01C1A20C.781D06C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Comments on 22 rev of the draft
Hi=20 Bernie,
See my=20 reply inline prefixed by VB3>
BV3> You=20 are forgetting ONE case ... what if the client was allowed to =
unicast to the server. In that case, we really do need to use = the=20 address
supplied by the client as that is = the only way=20 the server can determine
were the client=20 is.  
 
VB3> This is=20 where the problem arises. If the = client network
has two=20 prefixes, 3ffe::/64 and 5ffe::/64 and the client=20 wants
the=20 address with 3ffe::/64 prefix, it has = not the flexibility=20 of 
choosing the=20 source address. The source address selection
algorithm may=20 choose any address. It is based on the=20 destination
address. If the=20 destination address (server addr) = is 5ffe::/64,
then=20 the source address selection chooses the source=20 address
from 5ffe::/64 only. So, the=20 subnet selection option is the only
way of=20 indicating the client's wish of the prefix.

And you are not considering the rules for the source = address=20 that the
client is supposed to be using. So, = if we=20 assume clients are playing by
the rules = (which they=20 MUST IMHO), you have the following possibilities:
1)=20 The client is communicating via a relay agent. In that case things = are=20
easy since the server receives a Reply-Forw. =
2) The client is on the local link (and NOT unicasting), in = that=20 case
the client's address MUST be the = link-local=20 address and the server uses
the interface on = which the=20 request was received.
3) The client is = UNICASTING=20 because the server has allowed it to do so.
In that=20 case, the server MUST use the client's source address to = determine=20
the address. The client MUST also use a source = address that=20 is of sufficient
scope to reach the server. = Ideally,=20 this should be a global address as that
avoids any=20 issues with the client moving to a new link (since global = addresses=20
are "valid" anywhere).  

 

VB3> I am=20 sure that global address is unique over the world, but i am not=20 sure,
whether = it is valid=20 anywhere. I am not sure, whether the host with
subnet = preifx=20 3ffe::/64 moved to 5ffe::/64, will be able to receive the =
packet = with destined=20 to its 3ffe::/64 address.

 In = this case you=20 also don't have any problems because
if the = client has=20 moved to a new link, it should be sending a CONFIRM which =
is *NOT* unicast.  

VB3> = Regarding the=20 confirm, i have few doubts.
- draft says that, when the client moves to = new link,=20 it has to send confirm
message. How can the host identify it has = moved to a=20 new network?
Are we taking care of ICMP error=20 messages?
- Link local address is unique within the = link. When=20 a node is moved
from one link to another one, we cannot = surely say=20 that the link local
address is unique. What will happen, the = link local=20 address of the
interface is used by some other node in = that link?=20
- since, this address is the one, which has to be used as = source=20 address for confirm,
does the client has to do a ND first for = confirming=20 uniqueness within the link?
 
VB3> As i told earlier, a text has to be = added for=20 checking whether the addresses
in the IA has the same prefix as that of = the link it=20 resides, when confirm message
is received in the server. Otherwise, = the=20 confirm will get a positive = reply from=20 the
server, resulting in defeat of the purpose = of=20 confirm.
 
VB3> Here, i have another doubt. Assume = the=20 following scenario.
Assume the Relay agent has addresses from = two prefix=20 A and B
in the link attached to the client. Client = has some=20 addresses of
prefix A. It has  been rebooted now. = So, it=20 sends the confirm packet.
The confirm is received in the relay = agent's=20 interface. Now, what
prefix it has to put in the link-address = field. If it=20 chooses to put B,
then the addresses assigned to client = becomes=20 invalid. In what
basis, the Relay agent chooses the = prefixes, if the=20 interface
attached to the client's link has more than = one=20 prefixes?
 
------=_NextPart_000_0005_01C1A20C.781D06C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 13:56:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14811; Sun, 20 Jan 2002 13:56:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23990; Sun, 20 Jan 2002 13:55:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23959 for ; Sun, 20 Jan 2002 13:55:32 -0500 (EST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14808 for ; Sun, 20 Jan 2002 13:55:28 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel12.hp.com (Postfix) with ESMTP id 4D7A8E00093; Sun, 20 Jan 2002 10:54:58 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id AAA25399; Mon, 21 Jan 2002 00:20:40 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , Cc: , "Vijayabhaskar A K (E-mail)" Subject: RE: [dhcwg] additional option for dhcpv6 Date: Mon, 21 Jan 2002 00:25:57 +0530 Message-ID: <000b01c1a1e4$18c602d0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C1A212.327E3ED0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC6@EAMBUNT705> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1A212.327E3ED0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: [dhcwg] additional option for dhcpv6Bernie, I didn't talked anything about DDNS updates for temporary addresses. What i have defined is similar one like "hostname" option (option 12) in DHCPv4. It has the same functionality as option 12 in DHCPv4. If there is any FQDN related to address assigned, i wanted an option that informs the FQDN to client. This can be used for transfering hostnames/FQDN from client to server and vise versa. This holds for both normal addresses and temp addresses also. It is just a "hostname" option not an FQDN option. Since, DDNS updates is still TBD, i don't know, what are the fields needed for FQDN option. Let us decide whether the client or server is doing dns updates. Then based on that,we can decide the fields on FQDN option. I feel that if we are strictly moving some part or complete dns updates to client, we don't need one or both of the RCODE*. Do correct me, if i am wrong. Vijay: I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: - a 16-bit option number/option length - "A" RRs replaced by "AAAA" RRs. - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). ------=_NextPart_000_000C_01C1A212.327E3ED0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional option for dhcpv6
Bernie,
I didn't talked anything about=20 DDNS=20 updates for temporary addresses.=20 What i have defined is similar = one like=20 "hostname" option (option 12) in  DHCPv4. It has the same=20 functionality as option 12 in DHCPv4. If there is any FQDN related to = address assigned, i wanted an option = that informs=20 the FQDN to client. This can be used for transfering hostnames/FQDN from = client=20 to server and vise versa. This holds for both normal addresses and temp=20 addresses also. It is just a "hostname" option not an FQDN=20 option.
 
Since, DDNS updates is still TBD, i don't = know, what=20 are the fields needed for FQDN option. Let us decide whether the client = or=20 server is doing dns updates. Then based on=20 that,we=20 can decide the fields on FQDN option. I feel that if we are = strictly moving=20 some=20 part or complete dns updates to client, we don't need one or both of the = RCODE*.  Do correct me, if i am wrong.=20
 
Vijay:

I don't understand your desire to do DDNS updates = for=20 temporary addresses. We specifically do NOT want to do them. The -22 = draft=20 just says that if a server does DDNS updates, it must follow the rules = of RFC=20 3041.

I think you have things backwards a bit. = Non-temporary=20 addresses are the addresses that need domain names (FQDNs) assoicated = with=20 them. Temporary addresses really shouldn't since that defeats the = purpose of=20 temporary addresses. However, what RFC 3041 says, is that if DDNS = updates are=20 done, the name should be something that doesn't identify the client. = It gives=20 one reason for doing this and that is to keep applications happy that=20 "authenticate" clients by doing a reverse and then forward lookup to = assure=20 the client is in DNS. 

 We need a general FQDN option. Where it is placed = (encapulated within=20 the option area of an IA Address option, inside the option area of an = IA=20 option, or outside IA options) determines its scope (to one address, = several=20 addresses, or all addresses). For temporary addresses, the scope = should be to=20 that one address (since even using the same name with two temporary = addresses=20 could leak information about the client).

So, I see no value in an option that is just for = temporary=20 addresses. We should define a FQDN option and use it whenever DDNS = updates are=20 done. The format should be defined as in = draft-ietf-dhc-fqdn-option-03.txt=20 with the following differences:

- a 16-bit option number/option length =
- "A" RRs replaced by "AAAA" RRs.
- = Name=20 encoding should be as per section 10 of the -22 draft on DNS encodings = (hence=20 we technically don't need the "E" bit in the flag field but I would = recommend=20 we simply specify it MUST always be set to allow common code to be = used on the=20 client and/or server).

------=_NextPart_000_000C_01C1A212.327E3ED0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 14:14:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14967; Sun, 20 Jan 2002 14:14:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24742; Sun, 20 Jan 2002 14:13:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24721 for ; Sun, 20 Jan 2002 14:13:45 -0500 (EST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14961 for ; Sun, 20 Jan 2002 14:13:41 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel9.hp.com (Postfix) with ESMTP id 507AEE002D2 for ; Sun, 20 Jan 2002 14:13:13 -0500 (EST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id AAA26612; Mon, 21 Jan 2002 00:38:56 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Cc: "Vijayabhaskar A K (E-mail)" Date: Mon, 21 Jan 2002 00:44:12 +0530 Message-ID: <001701c1a1e6$a5aca670$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Error codes for Decline message Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit We need error codes to be defined for Decline message. AddrInUse - Address already in use. Is there any other scenario for which the client can send decline message? Will the following scenarios contribute to decline message? - The lease time the client has got is not sufficient for it. - The client has asked for a prefix A. But the server's admin policy says that for that client assign address with prefix B and it does so. I think, a mere release is not enough for these above situations. This has to be notified to the admin to take corrective action. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 16:12:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16217; Sun, 20 Jan 2002 16:12:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27424; Sun, 20 Jan 2002 16:11:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27352 for ; Sun, 20 Jan 2002 16:11:52 -0500 (EST) Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16198 for ; Sun, 20 Jan 2002 16:11:46 -0500 (EST) Received: (qmail 16930 invoked by uid 511); 20 Jan 2002 21:11:13 -0000 Message-ID: <20020120211113.16929.qmail@quiet-like-a-panther.org> References: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> From: Michael Johnston To: "Bernie Volz \(EUD\)" Cc: "'Jim Bound'" , dhcwg Date: Sun, 20 Jan 2002 21:11:13 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit This would work for me. I do not really see a need for making VUID length a bit count versus an octet count, but it is just a shift away. %%michael Bernie Volz (EUD) writes: > What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway. > > So, in 11.3 we could change it to be: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VUID length (in bits) | VUID (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . VUID (variable length) | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . domain name (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > VUID length is the number of bits of the VUID. > > VUID is the VUID (of (VUID length + 7)/8 bytes). > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Sunday, January 20, 2002 12:52 PM > To: Michael Johnston > Cc: Bernie Volz (EUD); dhcwg > Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments > > > Infiniband spec uses 128 bit global UIDs too. I think it makes sense to > have a 128bit option but keep the 64bit too. If we can just add it as > another option which I think we can. But we don't want to hold up the > spec either. > > > /jim > > > On Sun, 20 Jan 2002, Michael Johnston wrote: > >> Bernie, >> >> Intel-ish systems are what I use the most, so my information is skewed in >> that direction. >> >> The UUIDs being used today are derived from the algorithm in this document: >> http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt >> >> Mechanisms for retrieving (and in many cases storing) the platform UUID from >> (to) non-volatile storage are included in (or with) most x86PC compatible >> laptop and desktop systems and all Intel Itanium workstations and servers. >> >> In order to get Microsoft WHQL or Intel WfM certification all systems with >> network boot support must contain or generate a valid platform UUID. >> >> EFI (Extensible Firmware Interface) also requires a platform UUID. >> >> >> %%michael >> >> >> Bernie Volz (EUD) writes: >> >> > Hi: >> > >> > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). >> > >> > Do you or does anyone else have some good information about the what new systems are using for UUIDs? >> > >> > - Bernie Volz >> > >> > -----Original Message----- >> > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] >> > Sent: Saturday, January 19, 2002 3:00 PM >> > To: dhcwg >> > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments >> > >> > >> > Gentles, >> > >> > For the DUID contents definition (Section 11): >> > >> > Would you be adverse to expanding the size of the VUID to 128 bits or >> > creating an additional type (4) for a 128 bit UUID? >> > >> > Reasoning: >> > >> > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT >> > change over time...". From what I have seen, most new laptops, desktops & >> > workstations (especially those that come with network installed) already >> > contain, or have space reserved for, a 128 bit UUID that is intended to be >> > used to manage/track the system identity. Why have a vendor or IT assign >> > yet another ID number to the system. >> > >> > Using the link-layer address is also not a unique solution. Consider the >> > two cases of (1) laptops connecting to docking stations that contain network >> > adapters and (2) replacing defective or upgrading to new network adapters. >> > >> > >> > %%michael >> > >> > _______________________________________________ >> > dhcwg mailing list >> > dhcwg@ietf.org >> > https://www1.ietf.org/mailman/listinfo/dhcwg >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 19:23:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17741; Sun, 20 Jan 2002 19:23:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01815; Sun, 20 Jan 2002 19:23:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01792 for ; Sun, 20 Jan 2002 19:23:04 -0500 (EST) Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17735 for ; Sun, 20 Jan 2002 19:23:01 -0500 (EST) Received: (qmail 17649 invoked by uid 511); 21 Jan 2002 00:22:31 -0000 Message-ID: <20020121002231.17648.qmail@quiet-like-a-panther.org> From: Michael Johnston To: "dhcwg" Date: Mon, 21 Jan 2002 00:22:31 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Am I missing something? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit There is no bootfile or TFTP server information in the DHCPv6 draft. Maybe this is intentional. Is there another mechanism that is to be used by network boot clients to locate image servers and download images? %%michael _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 20:16:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18157; Sun, 20 Jan 2002 20:16:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03459; Sun, 20 Jan 2002 20:16:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03431 for ; Sun, 20 Jan 2002 20:16:03 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18149 for ; Sun, 20 Jan 2002 20:15:57 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01918; Sun, 20 Jan 2002 20:15:53 -0500 Date: Sun, 20 Jan 2002 20:15:53 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: Michael Johnston , dhcwg Subject: RE: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, This is a good idea I think. /jim On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote: > What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway. > > So, in 11.3 we could change it to be: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VUID length (in bits) | VUID (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . VUID (variable length) | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . domain name (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > VUID length is the number of bits of the VUID. > > VUID is the VUID (of (VUID length + 7)/8 bytes). > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Sunday, January 20, 2002 12:52 PM > To: Michael Johnston > Cc: Bernie Volz (EUD); dhcwg > Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments > > > Infiniband spec uses 128 bit global UIDs too. I think it makes sense to > have a 128bit option but keep the 64bit too. If we can just add it as > another option which I think we can. But we don't want to hold up the > spec either. > > > /jim > > > On Sun, 20 Jan 2002, Michael Johnston wrote: > > > Bernie, > > > > Intel-ish systems are what I use the most, so my information is skewed in > > that direction. > > > > The UUIDs being used today are derived from the algorithm in this document: > > http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt > > > > Mechanisms for retrieving (and in many cases storing) the platform UUID from > > (to) non-volatile storage are included in (or with) most x86PC compatible > > laptop and desktop systems and all Intel Itanium workstations and servers. > > > > In order to get Microsoft WHQL or Intel WfM certification all systems with > > network boot support must contain or generate a valid platform UUID. > > > > EFI (Extensible Firmware Interface) also requires a platform UUID. > > > > > > %%michael > > > > > > Bernie Volz (EUD) writes: > > > > > Hi: > > > > > > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). > > > > > > Do you or does anyone else have some good information about the what new systems are using for UUIDs? > > > > > > - Bernie Volz > > > > > > -----Original Message----- > > > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] > > > Sent: Saturday, January 19, 2002 3:00 PM > > > To: dhcwg > > > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments > > > > > > > > > Gentles, > > > > > > For the DUID contents definition (Section 11): > > > > > > Would you be adverse to expanding the size of the VUID to 128 bits or > > > creating an additional type (4) for a 128 bit UUID? > > > > > > Reasoning: > > > > > > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT > > > change over time...". From what I have seen, most new laptops, desktops & > > > workstations (especially those that come with network installed) already > > > contain, or have space reserved for, a 128 bit UUID that is intended to be > > > used to manage/track the system identity. Why have a vendor or IT assign > > > yet another ID number to the system. > > > > > > Using the link-layer address is also not a unique solution. Consider the > > > two cases of (1) laptops connecting to docking stations that contain network > > > adapters and (2) replacing defective or upgrading to new network adapters. > > > > > > > > > %%michael > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 20:22:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18219; Sun, 20 Jan 2002 20:22:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03607; Sun, 20 Jan 2002 20:22:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03576 for ; Sun, 20 Jan 2002 20:22:10 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18214 for ; Sun, 20 Jan 2002 20:22:04 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06468; Sun, 20 Jan 2002 20:20:12 -0500 Date: Sun, 20 Jan 2002 20:20:12 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'Vijay Bhaskar A K'" , mjs@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC6@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Folks, I have mixed feelings. I see Vijay's point but I also agree with Bernie. I suggest we not in DHC6 try to resolve the rules for DDNS and just make sure we have mechanism to permit DHC6 process FQDN's. Temp addr RFC 3041, DDSN, and FQDN DHC specs define the rules and interoperability issues. I suggest we not try to do that in DHC6. /jim On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote: > Vijay: > > I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. > > I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. > > We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). > > So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: > - a 16-bit option number/option length > - "A" RRs replaced by "AAAA" RRs. > - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Sunday, January 20, 2002 9:34 AM > To: mjs@cisco.com > Cc: vijayak@india.hp.com; dhcwg@ietf.org > Subject: Re: [dhcwg] additional option for dhcpv6 > > > Mark, > > Thanks for your thorough review. See my comments inline. > > ~ Vijay > > > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > > dhcpv4. > > The option i defined here is, for just transfering the FQDN releated to > temporary address. It is similar to hostname option in DHCPv4. I > will rename it to hostname option. I feel like, since the DDNS updates > are still TBD, we can define the FQDN option with appropriate fields > needed later, once DDNS specs are finalised. > > > The name encoding must be specified. > > Yes. It is needed. I will add the appropriate text. > > > There needs to be > > specification about hosts who do not initially know their entire fqdn. > > There needs to be a way to communicate about which party (if any) will be > > updating DNS. It's probably on my plate to produce that, actually. > > For the temporary addresses, DNS update is done by server. So, these > fields are not necessary. > > > > > 2) The subnet-selection option text should not compel the server to somehow > > obey the client's suggestion. It should be explict that the server > > administrator's configuration takes precedence, and that the client's > > indication that it desires a specific subnet can only be a hint that's > > considered along with all of the other information available to the server. > > This is the only way the client can tell its prefernce for the prefix. > If the server is not supposed to allocate address for that prefix, then > it wont. If the client is not very particular about the prefix, it > should not use this option. This option will be more helpful in the > network with two prefixes and the client wants a particular one. > > > > > A nit: isn't the option-len sufficient to determine the prefix length? Is > > the prefix-len byte necessary? > > No, it is not sufficient. Without the prefix-len field, you cannot find > out the exact prefix length. For example, you can identify whether the > prefix length is between 57 and 64. You cannot find out the exact > prefix length. > > > > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > > options should be DNS encoding, shouldn't it? That seems more robust than > > ASCII to me. > > Agreed. > > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > 'typed-scope-list-len' field before the 'DA address', rather than before > > the 'typed scope list'. Couldn't the length of the list immediately precede > > the list? > > I think, it won't make any difference. Let me know, if there are any > serious issues on this. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 20:31:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18353; Sun, 20 Jan 2002 20:31:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04228; Sun, 20 Jan 2002 20:31:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04189 for ; Sun, 20 Jan 2002 20:31:08 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18341 for ; Sun, 20 Jan 2002 20:31:04 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA10488; Sun, 20 Jan 2002 20:29:50 -0500 Date: Sun, 20 Jan 2002 20:29:50 -0500 (EST) From: Jim Bound To: Vijayabhaskar A K Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Error codes for Decline message In-Reply-To: <001701c1a1e6$a5aca670$2f290a0f@india.hp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Vijay, Your ahead of us with hands on code for dhc6. And thanks for putting it in the public domain that was very nice. We are trying to get to PS. I suggest that we will find more needed error codes once we begin more implementations and more error codes. Right now I believe we have the generic onces to to resolve a response for all errors trying to extrapolate the possibilities from the spec without writing the code myself. So I think adding a new code before PS as you have found as bonifided implementor is good. But I caution the WG positively to not head down all these paths we will find many new pieces we need from more implementation and getting to PS is important so other folks are not implementing specs 3 revs behind as it has engineering cost and thats part of our job in the IETF is to keep that to a minimum in our work for the folks that write code. /jim On Mon, 21 Jan 2002, Vijayabhaskar A K wrote: > We need error codes to be defined for Decline message. > AddrInUse - Address already in use. > Is there any other scenario for which the client can > send decline message? > Will the following scenarios contribute to decline message? > - The lease time the client has got is not sufficient for it. > - The client has asked for a prefix A. But the server's > admin policy says that for that client assign address > with prefix B and it does so. > I think, a mere release is not enough for these above > situations. This has to be notified to the admin to take > corrective action. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 20:40:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18450; Sun, 20 Jan 2002 20:40:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04412; Sun, 20 Jan 2002 20:39:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04382 for ; Sun, 20 Jan 2002 20:39:42 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18442 for ; Sun, 20 Jan 2002 20:39:38 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12138; Sun, 20 Jan 2002 20:39:39 -0500 Date: Sun, 20 Jan 2002 20:39:39 -0500 (EST) From: Jim Bound To: Michael Johnston Cc: dhcwg Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <20020121002231.17648.qmail@quiet-like-a-panther.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Michael, This as a note showed up in some work I did for Infinband engineers who chose IPv6 as the address to do that DL/API layer. We may need an option for a path to the boot file image but the approach we took for AD proto code was as follows (back at about draft 15 with mini dhc6 code base) Use dhc6 to find the SLP server. Use SLP protocol and servers to find the image file. So the question is with dhc6 is this the job of SLP now as we have transfered other things to SLP within the thinking model of dhc6? Also most server vendors that will build dhc6 will have SLP for IPv6 too? /jim On Mon, 21 Jan 2002, Michael Johnston wrote: > There is no bootfile or TFTP server information in the DHCPv6 draft. Maybe > this is intentional. Is there another mechanism that is to be used by > network boot clients to locate image servers and download images? > > %%michael > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 20 20:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18487; Sun, 20 Jan 2002 20:42:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04504; Sun, 20 Jan 2002 20:42:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04486 for ; Sun, 20 Jan 2002 20:42:30 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18482 for ; Sun, 20 Jan 2002 20:42:23 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06438; Sun, 20 Jan 2002 20:41:01 -0500 Date: Sun, 20 Jan 2002 20:41:01 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'Vijay Bhaskar A K'" , mjs@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org whoops meant DDNS not DDSN below. .jim /jim On Sun, 20 Jan 2002, Jim Bound wrote: > Folks, > > I have mixed feelings. I see Vijay's point but I also agree with Bernie. > I suggest we not in DHC6 try to resolve the rules for DDNS and just make > sure we have mechanism to permit DHC6 process FQDN's. Temp addr RFC > 3041, DDSN, and FQDN DHC specs define the rules and interoperability > issues. I suggest we not try to do that in DHC6. > > > /jim > > > On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote: > > > Vijay: > > > > I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. > > > > I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. > > > > We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). > > > > So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: > > - a 16-bit option number/option length > > - "A" RRs replaced by "AAAA" RRs. > > - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). > > > > - Bernie > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Sunday, January 20, 2002 9:34 AM > > To: mjs@cisco.com > > Cc: vijayak@india.hp.com; dhcwg@ietf.org > > Subject: Re: [dhcwg] additional option for dhcpv6 > > > > > > Mark, > > > > Thanks for your thorough review. See my comments inline. > > > > ~ Vijay > > > > > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > > > dhcpv4. > > > > The option i defined here is, for just transfering the FQDN releated to > > temporary address. It is similar to hostname option in DHCPv4. I > > will rename it to hostname option. I feel like, since the DDNS updates > > are still TBD, we can define the FQDN option with appropriate fields > > needed later, once DDNS specs are finalised. > > > > > The name encoding must be specified. > > > > Yes. It is needed. I will add the appropriate text. > > > > > There needs to be > > > specification about hosts who do not initially know their entire fqdn. > > > There needs to be a way to communicate about which party (if any) will be > > > updating DNS. It's probably on my plate to produce that, actually. > > > > For the temporary addresses, DNS update is done by server. So, these > > fields are not necessary. > > > > > > > > 2) The subnet-selection option text should not compel the server to somehow > > > obey the client's suggestion. It should be explict that the server > > > administrator's configuration takes precedence, and that the client's > > > indication that it desires a specific subnet can only be a hint that's > > > considered along with all of the other information available to the server. > > > > This is the only way the client can tell its prefernce for the prefix. > > If the server is not supposed to allocate address for that prefix, then > > it wont. If the client is not very particular about the prefix, it > > should not use this option. This option will be more helpful in the > > network with two prefixes and the client wants a particular one. > > > > > > > > A nit: isn't the option-len sufficient to determine the prefix length? Is > > > the prefix-len byte necessary? > > > > No, it is not sufficient. Without the prefix-len field, you cannot find > > out the exact prefix length. For example, you can identify whether the > > prefix length is between 57 and 64. You cannot find out the exact > > prefix length. > > > > > > > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > > > options should be DNS encoding, shouldn't it? That seems more robust than > > > ASCII to me. > > > > Agreed.. > > > > > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > > 'typed-scope-list-len' field before the 'DA address', rather than before > > > the 'typed scope list'. Couldn't the length of the list immediately precede > > > the list? > > > > I think, it won't make any difference. Let me know, if there are any > > serious issues on this. > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 02:30:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02031; Mon, 21 Jan 2002 02:30:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23423; Mon, 21 Jan 2002 02:29:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23347 for ; Mon, 21 Jan 2002 02:29:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02001 for ; Mon, 21 Jan 2002 02:29:03 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0L7SaS09076 for ; Mon, 21 Jan 2002 01:28:36 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0L7Saf06140 for ; Mon, 21 Jan 2002 01:28:36 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 21 01:28:35 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 01:28:34 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC9@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Mon, 21 Jan 2002 01:28:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24D.3B39A6A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A24D.3B39A6A0 Content-Type: text/plain; charset="iso-8859-1" Vijay: How a client determines it has (possibly) moved to a new link is a client issue. If you're using wired Ethernet, the client can easily detect when the cable is disconnected/reconnected. If a client powers on (from Standby, etc), it should assume it MAY have moved to a new link and Confirm. The DHCP server, as in IPv4, needs complete network configuration information. If you don't provide it all of the information it needs to operate, it will not be able to service clients successfully. This is true in IPv4 today and if you have multiple prefixes active on a single link, you need to tell the DHCP server this. See below (prefixed by BV4>). - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Sunday, January 20, 2002 1:15 PM To: 'Bernie Volz (EUD)' Cc: dhcwg@ietf.org; vijayak@india.hp.com Subject: RE: [dhcwg] Comments on 22 rev of the draft Hi Bernie, See my reply inline prefixed by VB3> BV3> You are forgetting ONE case ... what if the client was allowed to unicast to the server. In that case, we really do need to use the address supplied by the client as that is the only way the server can determine were the client is. VB3> This is where the problem arises. If the client network has two prefixes, 3ffe::/64 and 5ffe::/64 and the client wants the address with 3ffe::/64 prefix, it has not the flexibility of choosing the source address. The source address selection algorithm may choose any address. It is based on the destination address. If the destination address (server addr) is 5ffe::/64, then the source address selection chooses the source address from 5ffe::/64 only. So, the subnet selection option is the only way of indicating the client's wish of the prefix. And you are not considering the rules for the source address that the client is supposed to be using. So, if we assume clients are playing by the rules (which they MUST IMHO), you have the following possibilities: 1) The client is communicating via a relay agent. In that case things are easy since the server receives a Reply-Forw. 2) The client is on the local link (and NOT unicasting), in that case the client's address MUST be the link-local address and the server uses the interface on which the request was received. 3) The client is UNICASTING because the server has allowed it to do so. In that case, the server MUST use the client's source address to determine the address. The client MUST also use a source address that is of sufficient scope to reach the server. Ideally, this should be a global address as that avoids any issues with the client moving to a new link (since global addresses are "valid" anywhere). VB3> I am sure that global address is unique over the world, but i am not sure, whether it is valid anywhere. I am not sure, whether the host with subnet preifx 3ffe::/64 moved to 5ffe::/64, will be able to receive the packet with destined to its 3ffe::/64 address. BV4> The client has to Confirm the address when it detects that it may have moved. In this case you also don't have any problems because if the client has moved to a new link, it should be sending a CONFIRM which is *NOT* unicast. VB3> Regarding the confirm, i have few doubts. - draft says that, when the client moves to new link, it has to send confirm message. How can the host identify it has moved to a new network? Are we taking care of ICMP error messages? BV4> See above. - Link local address is unique within the link. When a node is moved from one link to another one, we cannot surely say that the link local address is unique. What will happen, the link local address of the interface is used by some other node in that link? BV4> How the link local address is determined is controlled by Stateless Autoconfiguration. If a client believes the link has changed, it should take steps to make sure that the link-local address it wants to use (was using) is still valid and not duplicated. - since, this address is the one, which has to be used as source address for confirm, does the client has to do a ND first for confirming uniqueness within the link? BV4> Only a valid link local address (per stateless autoconfiguration) may be used. VB3> As i told earlier, a text has to be added for checking whether the addresses in the IA has the same prefix as that of the link it resides, when confirm message is received in the server. Otherwise, the confirm will get a positive reply from the server, resulting in defeat of the purpose of confirm. VB3> Here, i have another doubt. Assume the following scenario. Assume the Relay agent has addresses from two prefix A and B in the link attached to the client. Client has some addresses of prefix A. It has been rebooted now. So, it sends the confirm packet. The confirm is received in the relay agent's interface. Now, what prefix it has to put in the link-address field. If it chooses to put B, then the addresses assigned to client becomes invalid. In what basis, the Relay agent chooses the prefixes, if the interface attached to the client's link has more than one prefixes? BV4> You have misconfigured your DHCP environment. Fix the configuration so that either the relay always supplies the correct prefix or configure the DHCPv6 server to know about both prefixes. ------_=_NextPart_001_01C1A24D.3B39A6A0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Comments on 22 rev of the draft
Vijay:
 
How a client determines it has (possibly) moved to a new link is a client issue. If you're using wired Ethernet, the client can easily detect when the cable is disconnected/reconnected. If a client powers on (from Standby, etc), it should assume it MAY have moved to a new link and Confirm.
 
The DHCP server, as in IPv4, needs complete network configuration information. If you don't provide it all of the information it needs to operate, it will not be able to service clients successfully. This is true in IPv4 today and if you have multiple prefixes active on a single link, you need to tell the DHCP server this.
 
See below (prefixed by BV4>).
 
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Sunday, January 20, 2002 1:15 PM
To: 'Bernie Volz (EUD)'
Cc: dhcwg@ietf.org; vijayak@india.hp.com
Subject: RE: [dhcwg] Comments on 22 rev of the draft

Hi Bernie,
See my reply inline prefixed by VB3>
BV3> You are forgetting ONE case ... what if the client was allowed to
unicast to the server. In that case, we really do need to use the address
supplied by the client as that is the only way the server can determine
were the client is.  
 
VB3> This is where the problem arises. If the client network
has two prefixes, 3ffe::/64 and 5ffe::/64 and the client wants
the address with 3ffe::/64 prefix, it has not the flexibility of 
choosing the source address. The source address selection
algorithm may choose any address. It is based on the destination
address. If the destination address (server addr) is 5ffe::/64,
then the source address selection chooses the source address
from 5ffe::/64 only. So, the subnet selection option is the only
way of indicating the client's wish of the prefix.

And you are not considering the rules for the source address that the
client is supposed to be using. So, if we assume clients are playing by
the rules (which they MUST IMHO), you have the following possibilities:
1) The client is communicating via a relay agent. In that case things are
easy since the server receives a Reply-Forw.
2) The client is on the local link (and NOT unicasting), in that case
the client's address MUST be the link-local address and the server uses
the interface on which the request was received.
3) The client is UNICASTING because the server has allowed it to do so.
In that case, the server MUST use the client's source address to determine
the address. The client MUST also use a source address that is of sufficient
scope to reach the server. Ideally, this should be a global address as that
avoids any issues with the client moving to a new link (since global addresses
are "valid" anywhere).  

 

VB3> I am sure that global address is unique over the world, but i am not sure,
whether it is valid anywhere. I am not sure, whether the host with
subnet preifx 3ffe::/64 moved to 5ffe::/64, will be able to receive the
packet with destined to its 3ffe::/64 address. 
 
BV4> The client has to Confirm the address when it detects that it may have moved. 

 In this case you also don't have any problems because
if the client has moved to a new link, it should be sending a CONFIRM which
is *NOT* unicast.  

VB3> Regarding the confirm, i have few doubts.
- draft says that, when the client moves to new link, it has to send confirm
message. How can the host identify it has moved to a new network?
Are we taking care of ICMP error messages? 
 
BV4> See above.
 
- Link local address is unique within the link. When a node is moved
from one link to another one, we cannot surely say that the link local
address is unique. What will happen, the link local address of the
interface is used by some other node in that link?  
 
BV4> How the link local address is determined is controlled by Stateless Autoconfiguration.
If a client believes the link has changed, it should take steps to make sure that the link-local
address it wants to use (was using) is still valid and not duplicated.
 
- since, this address is the one, which has to be used as source address for confirm,
does the client has to do a ND first for confirming uniqueness within the link? 
 
BV4> Only a valid link local address (per stateless autoconfiguration) may be used. 
 
VB3> As i told earlier, a text has to be added for checking whether the addresses
in the IA has the same prefix as that of the link it resides, when confirm message
is received in the server. Otherwise, the confirm will get a positive reply from the
server, resulting in defeat of the purpose of confirm.
 
VB3> Here, i have another doubt. Assume the following scenario.
Assume the Relay agent has addresses from two prefix A and B
in the link attached to the client. Client has some addresses of
prefix A. It has  been rebooted now. So, it sends the confirm packet.
The confirm is received in the relay agent's interface. Now, what
prefix it has to put in the link-address field. If it chooses to put B,
then the addresses assigned to client becomes invalid. In what
basis, the Relay agent chooses the prefixes, if the interface
attached to the client's link has more than one prefixes?
 
BV4> You have misconfigured your DHCP environment. Fix the configuration so that either
the relay always supplies the correct prefix or configure the DHCPv6 server to know about
both prefixes.
------_=_NextPart_001_01C1A24D.3B39A6A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 02:38:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02186; Mon, 21 Jan 2002 02:38:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24029; Mon, 21 Jan 2002 02:38:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24004 for ; Mon, 21 Jan 2002 02:38:11 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02183 for ; Mon, 21 Jan 2002 02:38:07 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0L7beS09653 for ; Mon, 21 Jan 2002 01:37:40 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0L7bef06997 for ; Mon, 21 Jan 2002 01:37:40 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Jan 21 01:37:39 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 01:37:39 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDCA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , mjs@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 Date: Mon, 21 Jan 2002 01:37:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24E.80B8D470" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A24E.80B8D470 Content-Type: text/plain; charset="iso-8859-1" My feeling is that we should follow the work being done in DHCPv4 in this area (FQDN) as defined by draft-ietf-dhc-fqdn-option-03.txt. Whether we also have a host name option is still TBD - I believe Carl Smith and Ted Lemon will be working up some text for DHCPv4 and it would be good to wait until we have some clear definitions around proper behavior and interactions between the host name, domain name, and FQDN options. Unless there are some significant reasons to defer from DHCPv4 options, I would recommend using the DHCPv4 options as closely as possible. We have a lot of experience with those options already! - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Sunday, January 20, 2002 1:56 PM To: 'Bernie Volz (EUD)'; mjs@cisco.com Cc: dhcwg@ietf.org; Vijayabhaskar A K (E-mail) Subject: RE: [dhcwg] additional option for dhcpv6 Bernie, I didn't talked anything about DDNS updates for temporary addresses. What i have defined is similar one like "hostname" option (option 12) in DHCPv4. It has the same functionality as option 12 in DHCPv4. If there is any FQDN related to address assigned, i wanted an option that informs the FQDN to client. This can be used for transfering hostnames/FQDN from client to server and vise versa. This holds for both normal addresses and temp addresses also. It is just a "hostname" option not an FQDN option. Since, DDNS updates is still TBD, i don't know, what are the fields needed for FQDN option. Let us decide whether the client or server is doing dns updates. Then based on that,we can decide the fields on FQDN option. I feel that if we are strictly moving some part or complete dns updates to client, we don't need one or both of the RCODE*. Do correct me, if i am wrong. Vijay: I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: - a 16-bit option number/option length - "A" RRs replaced by "AAAA" RRs. - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). ------_=_NextPart_001_01C1A24E.80B8D470 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] additional option for dhcpv6
My feeling is that we should follow the work being done in DHCPv4 in this area (FQDN) as defined by draft-ietf-dhc-fqdn-option-03.txt. Whether we also have a host name option is still TBD - I believe Carl Smith and Ted Lemon will be working up some text for DHCPv4 and it would be good to wait until we have some clear definitions around proper behavior and interactions between the host name, domain name, and FQDN options. Unless there are some significant reasons to defer from DHCPv4 options, I would recommend using the DHCPv4 options as closely as possible. We have a lot of experience with those options already!
 
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Sunday, January 20, 2002 1:56 PM
To: 'Bernie Volz (EUD)'; mjs@cisco.com
Cc: dhcwg@ietf.org; Vijayabhaskar A K (E-mail)
Subject: RE: [dhcwg] additional option for dhcpv6

Bernie,
I didn't talked anything about DDNS updates for temporary addresses. What i have defined is similar one like "hostname" option (option 12) in  DHCPv4. It has the same functionality as option 12 in DHCPv4. If there is any FQDN related to address assigned, i wanted an option that informs the FQDN to client. This can be used for transfering hostnames/FQDN from client to server and vise versa. This holds for both normal addresses and temp addresses also. It is just a "hostname" option not an FQDN option.
 
Since, DDNS updates is still TBD, i don't know, what are the fields needed for FQDN option. Let us decide whether the client or server is doing dns updates. Then based on that,we can decide the fields on FQDN option. I feel that if we are strictly moving some part or complete dns updates to client, we don't need one or both of the RCODE*.  Do correct me, if i am wrong.
 
Vijay:

I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041.

I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. 

 We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client).

So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences:

- a 16-bit option number/option length
- "A" RRs replaced by "AAAA" RRs.
- Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server).

------_=_NextPart_001_01C1A24E.80B8D470-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 02:46:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02254; Mon, 21 Jan 2002 02:46:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24157; Mon, 21 Jan 2002 02:45:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24131 for ; Mon, 21 Jan 2002 02:45:11 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02249 for ; Mon, 21 Jan 2002 02:45:07 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0L7jAh03688 for ; Mon, 21 Jan 2002 01:45:10 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0L7jAf07686 for ; Mon, 21 Jan 2002 01:45:10 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 21 01:45:09 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 01:45:09 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDCB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" , Vijayabhaskar A K Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Error codes for Decline message Date: Mon, 21 Jan 2002 01:45:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24F.8C378750" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A24F.8C378750 Content-Type: text/plain; charset="iso-8859-1" I agree with Jim (we may want to add some additional error codes down the road). At one point in the discussions, we were about to abandon all error codes and simply have a success / failure indication. So, please think minimal error codes! I don't agree with Vijay's position that the two instances given are Decline cases. They should instead result in Releases (if a client doesn't want an address the server gave it, it should Release it). Also, other than for "logging", I don't believe the server really cares. Decline says to basically "Abandon" the address as it appears to be in use by a system already when it should not be. Release says just to release the addresses and place them back into the available pool of addresses. The status codes don't change the processing, IMHO. You don't even need to set them to specific values (the error codes are more for server to client communication in Reply's, IMHO). - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Sunday, January 20, 2002 8:30 PM To: Vijayabhaskar A K Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Error codes for Decline message Hi Vijay, Your ahead of us with hands on code for dhc6. And thanks for putting it in the public domain that was very nice. We are trying to get to PS. I suggest that we will find more needed error codes once we begin more implementations and more error codes. Right now I believe we have the generic onces to to resolve a response for all errors trying to extrapolate the possibilities from the spec without writing the code myself. So I think adding a new code before PS as you have found as bonifided implementor is good. But I caution the WG positively to not head down all these paths we will find many new pieces we need from more implementation and getting to PS is important so other folks are not implementing specs 3 revs behind as it has engineering cost and thats part of our job in the IETF is to keep that to a minimum in our work for the folks that write code. /jim On Mon, 21 Jan 2002, Vijayabhaskar A K wrote: > We need error codes to be defined for Decline message. > AddrInUse - Address already in use. > Is there any other scenario for which the client can > send decline message? > Will the following scenarios contribute to decline message? > - The lease time the client has got is not sufficient for it. > - The client has asked for a prefix A. But the server's > admin policy says that for that client assign address > with prefix B and it does so. > I think, a mere release is not enough for these above > situations. This has to be notified to the admin to take > corrective action. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A24F.8C378750 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Error codes for Decline message

I agree with Jim (we may want to add some additional error codes down the road).
At one point in the discussions, we were about to abandon all error codes and
simply have a success / failure indication. So, please think minimal error codes!

I don't agree with Vijay's position that the two instances given are Decline
cases. They should instead result in Releases (if a client doesn't want an address
the server gave it, it should Release it).

Also, other than for "logging", I don't believe the server really cares. Decline
says to basically "Abandon" the address as it appears to be in use by a system
already when it should not be.

Release says just to release the addresses and place them back into the available
pool of addresses.

The status codes don't change the processing, IMHO. You don't even need to set
them to specific values (the error codes are more for server to client communication
in Reply's, IMHO).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Sunday, January 20, 2002 8:30 PM
To: Vijayabhaskar A K
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Error codes for Decline message


Hi Vijay,

Your ahead of us with hands on code for dhc6.  And thanks for putting it
in the public domain that was very nice.  We are trying to get to PS.  I
suggest that we will find more needed error codes once we begin more
implementations and more error codes.  Right now I believe we have the
generic onces to to resolve a response for all errors trying to
extrapolate the possibilities from the spec without writing the code
myself.  So I think adding a new code before PS as you have found as
bonifided implementor is good.  But  I caution the WG positively to not
head down all these paths we will find many new pieces we need from more
implementation and getting to PS is important so other folks are not
implementing specs 3 revs behind as it has engineering cost and thats part
of our job in the IETF is to keep that to a minimum in our work for the
folks that write code.


/jim


On Mon, 21 Jan 2002, Vijayabhaskar A K wrote:

> We need error codes to be defined for Decline message.
> AddrInUse - Address already in use.
> Is there any other scenario for which the client can
> send decline message?
> Will the following scenarios contribute to decline message?
> - The lease time the client has got is not sufficient for it.
> - The client has asked for a prefix A. But the server's
> admin policy says that for that client assign address
> with prefix B and it does so.
> I think, a mere release is not enough for these above
> situations. This has to be notified to the admin to take
> corrective action.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A24F.8C378750-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 03:28:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02659; Mon, 21 Jan 2002 03:28:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25489; Mon, 21 Jan 2002 03:28:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25462 for ; Mon, 21 Jan 2002 03:28:06 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02652 for ; Mon, 21 Jan 2002 03:28:02 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0L8RGH81290; Mon, 21 Jan 2002 09:27:17 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 68309C05B; Mon, 21 Jan 2002 09:26:41 +0100 (CET) Date: Mon, 21 Jan 2002 09:26:41 +0100 From: Martin Stiemerling To: John Schnizlein , vijayak@india.hp.com Cc: "'Jim Bound'" , dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <11550000.1011601601@elgar> In-Reply-To: <4.3.2.7.2.20020118151943.01892130@diablo.cisco.com> References: <8140000.1011342023@elgar> <4.3.2.7.2.20020118151943.01892130@diablo.cisco.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit --On Freitag, Januar 18, 2002 15:22:36 -0500 John Schnizlein wrote: > At 01:05 PM 1/18/2002, Vijayabhaskar A K wrote: > >> Please note that, there are no routers in the networks. That's why >> i mentioned that node as the one conneceted to two network and having >> ipv6forwarding enabled, instead of routers. This is for the networks >> which have not deployed IPv6 routing completely. I think there is no >> harm in having this option. > > If the purpose of the option is to enable situations where hosts > have ipv6forwarding enabled, but do not act as proper v6 routers, > then we should not support it. That is just bad practice. (IMHO) I totaly agree with this. > The use for tunnelling might be justifiable. This is, what I have mentioned some emails before. Give the child the proper name and it is OK. Martin > > John > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 09:44:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10912; Mon, 21 Jan 2002 09:44:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09764; Mon, 21 Jan 2002 09:43:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09742 for ; Mon, 21 Jan 2002 09:43:51 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10892 for ; Mon, 21 Jan 2002 09:43:48 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24010; Mon, 21 Jan 2002 09:43:21 -0500 (EST) Received: from MJS-PC.cisco.com (mjs-pc.cisco.com [172.27.181.69]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM58926; Mon, 21 Jan 2002 09:43:21 -0500 (EST) Message-Id: <4.3.2.7.2.20020121092051.021d8468@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 09:44:31 -0500 To: Vijay Bhaskar A K From: Mark Stapp Subject: Re: [dhcwg] additional option for dhcpv6 Cc: dhcwg@ietf.org In-Reply-To: <200201201434.UAA22474@dce.india.hp.com> References: <4.3.2.7.2.20020118165044.019a0ef0@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Vijay, 1) FQDN Option. I really think that we should use a single option that can convey both a complete FQDN or a partial 'hostname'. It's unnecessary to try to specify two options and the relationship between them. Certainly, there's no need to include the RCODE fields that were part of the v4 FQDN option: like the two name encodings in the v4 version, those fields were left in place because there was a large base of deployed clients who expected those fields to be present. I'd suggest that we specify the same method that's used in the v4 option to distinguish between fully-qualified and unqualified names: if the last label in the name field is null-length, the name is fully-qualified. If a client believes it knows a complete FQDN, it sends that name and terminates it accordingly. If it only knows a partial name, it sends the labels it knows. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. >For the temporary addresses, DNS update is done by server. So, these >fields are not necessary. As I said, I think that DNS updates will be performed by different parties in different environments, just as they are in IP4 networks. The option must contain enough information to permit a network's administrators to influence the choice of updater for zones that are under their control. Like Bernie, I don't know what you mean here when you claim that no additional data is necessary. Your claim that temporary addresses' updates will be done by servers is a little confusing to me. Why do you assume that? You imply that non-temporary updates are clearly understood to be the responsibility of one party. I disagree: I think that the years of field experience we have demonstrates that there are a variety of valid dns update models. > > > > 2) The subnet-selection option text should not compel the server to > somehow > > obey the client's suggestion. It should be explict that the server > > administrator's configuration takes precedence, and that the client's > > indication that it desires a specific subnet can only be a hint that's > > considered along with all of the other information available to the server. > >This is the only way the client can tell its prefernce for the prefix. >If the server is not supposed to allocate address for that prefix, then >it wont. If the client is not very particular about the prefix, it >should not use this option. This option will be more helpful in the >network with two prefixes and the client wants a particular one. I think that the specification must be clear about the behavior that the paragraph in your reply describes. The server MAY consider the subnet specified as it considers the other information available to it about its allocation policies and about the client. > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > 'typed-scope-list-len' field before the 'DA address', rather than before > > the 'typed scope list'. Couldn't the length of the list immediately > precede > > the list? > >I think, it won't make any difference. Let me know, if there are any >serious issues on this. There are so many examples of the field len/field value convention that I think it's much clearer to continue using that convention unless there's a very good reason not to. I don't think that there is such a reason in this case, and I think that it will make the specification and implementation of this option more robust if we retain that convention. -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 09:48:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11015; Mon, 21 Jan 2002 09:48:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09824; Mon, 21 Jan 2002 09:47:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09805 for ; Mon, 21 Jan 2002 09:47:36 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10999 for ; Mon, 21 Jan 2002 09:47:33 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24334; Mon, 21 Jan 2002 09:47:06 -0500 (EST) Received: from MJS-PC.cisco.com (mjs-pc.cisco.com [172.27.181.69]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM58968; Mon, 21 Jan 2002 09:47:05 -0500 (EST) Message-Id: <4.3.2.7.2.20020121094439.01942580@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 09:48:09 -0500 To: Michael Johnston From: Mark Stapp Subject: Re: [dhcwg] Am I missing something? Cc: dhcwg In-Reply-To: References: <20020121002231.17648.qmail@quiet-like-a-panther.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Michael, I agree with you. I don't think that we should force our users to deploy and configure any additional protocols in order to locate their ftp servers. Those servers are a fundamental part of the boot process in some environments, and that's what DHCP is for, right? FTP and TFTP server options should be part of the base option set. -- Mark On Mon, 21 Jan 2002, Michael Johnston wrote: > > There is no bootfile or TFTP server information in the DHCPv6 > draft. Maybe > > this is intentional. Is there another mechanism that is to be used by > > network boot clients to locate image servers and download images? > > > > %%michael > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 10:40:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12861; Mon, 21 Jan 2002 10:40:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13339; Mon, 21 Jan 2002 10:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13317 for ; Mon, 21 Jan 2002 10:39:57 -0500 (EST) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12813 for ; Mon, 21 Jan 2002 10:39:54 -0500 (EST) From: dworley@globespanvirata.com Received: from agranat.com (alice.agranat.com [10.21.0.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id KAA00981 for ; Mon, 21 Jan 2002 10:39:27 -0500 Received: from dhcp75.ma.virata.com (dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.11.6/8.11.6) with ESMTP id g0LFdQQ07512 for ; Mon, 21 Jan 2002 10:39:26 -0500 Received: (from worley@localhost) by dhcp75.ma.virata.com (8.11.0/8.11.0) id g0LFdQU10176; Mon, 21 Jan 2002 10:39:26 -0500 Date: Mon, 21 Jan 2002 10:39:26 -0500 Message-Id: <200201211539.g0LFdQU10176@dhcp75.ma.virata.com> X-Authentication-Warning: dhcp75.ma.virata.com: worley set sender to dworley@globespanvirata.com using -f To: dhcwg@ietf.org In-reply-to: <4.3.2.7.2.20020121094439.01942580@goblet.cisco.com> (message from Mark Stapp on Mon, 21 Jan 2002 09:48:09 -0500) Subject: Re: [dhcwg] Am I missing something? References: <20020121002231.17648.qmail@quiet-like-a-panther.org> <4.3.2.7.2.20020121094439.01942580@goblet.cisco.com> X-Scanned-By: MIMEDefang 2.2 (www dot roaringpenguin dot com slash mimedefang) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org From: Mark Stapp I agree with you. I don't think that we should force our users to deploy and configure any additional protocols in order to locate their ftp servers. Those servers are a fundamental part of the boot process in some environments, and that's what DHCP is for, right? FTP and TFTP server options should be part of the base option set. I'm not that familiar with DHCP usage, but my belief is that the most common use for DHCP is distributing IPv4 addresses, and the second-most-common use is for distributing TFTP addresses and file names for fetching boot images. If so, we would need a very strong reason for eliminating the FTP server options. Also, if the DHCP FTP server information is to be distributed by another mechanism, we must ensure that existing boot ROMs will be able to hold the code for the additional mechanism. If not, a vendor will recreate the FTP server options as a vendor-specific option, and 1,000 other vendors will copy it. Dale -- Dale R. WORLEY Director, ABU Engineering GlobespanVirata Applications Infrastructure http://emweb.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 14:20:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20692; Mon, 21 Jan 2002 14:20:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23837; Mon, 21 Jan 2002 14:19:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23811 for ; Mon, 21 Jan 2002 14:19:45 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20647 for ; Mon, 21 Jan 2002 14:19:36 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01776 for ; Mon, 21 Jan 2002 14:19:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020121141605.032339d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 14:19:36 -0500 To: "dhcwg" From: Ralph Droms Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <20020121002231.17648.qmail@quiet-like-a-panther.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org We've taken an "on-demand" approach to adding options to DHCPv6 - that is, as options are requested, we've added them. There hasn't been any intentional oversight; to avoid carrying forward unnecessary options (e.g., "Impress server"), we've simply started with a clean (or almost clean) slate. 'bootfile' and 'TFTP server' seem like good candidates for inclusion in DHCPv6. For WG discussion - should the 'bootfile' and 'TFTP server' options be carried over verbatim to DHCPv6 or are there changes that should be made? - Ralph At 12:22 AM 1/21/2002 +0000, Michael Johnston wrote: >There is no bootfile or TFTP server information in the DHCPv6 >draft. Maybe this is intentional. Is there another mechanism that is to >be used by network boot clients to locate image servers and download images? > >%%michael >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 14:58:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22059; Mon, 21 Jan 2002 14:58:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24908; Mon, 21 Jan 2002 14:57:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24887 for ; Mon, 21 Jan 2002 14:57:35 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22052 for ; Mon, 21 Jan 2002 14:57:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05939; Mon, 21 Jan 2002 14:53:22 -0500 (EST) Message-Id: <4.3.2.7.2.20020121144941.0324ff90@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 14:53:49 -0500 To: Vijay Bhaskar A K From: Ralph Droms Subject: Re: [dhcwg] Comments on 22 rev of the draft Cc: Bernie.Volz@am1.ericsson.se, vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <200201181738.XAA16245@dce.india.hp.com> References: <66F66129A77AD411B76200508B65AC69B4CDB4@EAMBUNT705> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 11:08 PM 1/18/2002 +0530, Vijay Bhaskar A K wrote: >Bernie, > >See my comments prefixed by VB2> > >~ Vijay > > > Vijay, see BV2> comments. > > > > - Bernie > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Thursday, January 17, 2002 4:35 AM > > To: Bernie.Volz@am1.ericsson.se > > Cc: vijayak@india.hp.com; dhcwg@ietf.org > > Subject: Re: [dhcwg] Comments on 22 rev of the draft > > > > > > See my comments inline prefixed by VB> > > > > ~Vijay > > > > > Let me try to answer these based on my understanding/view of -22. > > > > > > See below. > > > > > > - Bernie > > > > > > -----Original Message----- > > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > > Sent: Wednesday, January 16, 2002 1:05 PM > > > To: dhcwg@ietf.org > > > Cc: vijayak@dce.india.hp.com > > > Subject: [dhcwg] Comments on 22 rev of the draft > > > > > > > > > I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > > > in telling the comments. > > > >[...] > > > - Till what time, these OFFERED addresses are preserved for those > > > clients to assign? > > > > > > BV> My opinion is that the ADVERTISED addresses are just a possible > set of > > > addresses the client will get and may not be the exact addresses. The > client > > > must wait until the Reply to the Request before it knows which > addresses it > > > got and before it does Duplicate Address Detection. The ADVERTISE should > > > include all of the parameters the client is likely to receive in the > Reply, > > > but they are just possible values and not the actual values. > > > > VB> What i am asking is, in V4, there is a concept called OFFERED > > addresses, which will be reserved to a client. The server reserves that > > addresses for the some predefined time. At the expiration of the time, > > if the client has not sent the request, it will be allocated to some > > other clients. I disagree that DHCPv4 requires that a server explicitly reserve an address it has offered to a client. From RFC2131: 3.1 Client-server interaction - allocating a network address [...] 2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers need not ^^^^^^^^^^^^^^^^ reserve the offered network address, although the protocol will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ work more efficiently if the server avoids allocating the offered network address to another client. When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request. Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses. The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary. > I think, if we follow the same policy, it will be > > better. Assume, a client sends a SOLICIT and the server replies with > > ADVERTISE with some addresses. Before the client sending the Request, > > if some other client requests for the addresses, with the current > > mechanism, the server will assign the addresses to new client. It may > > lead to server to send AddrUnavail to the first client, if the server > > has only limited number of addresses. It will lead to unnecessary > > packet transactions. > > > > BV2> I don't agree. It is much better if the server can just send something > > out and not have to do anything to remember it. With IPv6, what's the > likelyhood > > that an address won't be available - we have 2^64 addresses on each prefix! > > > > BV2> What I view the ADVERTISE message to be is for the server to say I am > > willing to give you this stuff [assuming it is avaiable] but that I haven't > > given you the EXACT stuff you will get (since that happens in the Reply to > > the Request). > > > > BV2> BUT please note that this really is up to each SERVER to do what it > > wants. A SERVER can chose to ADVERTISE real stuff and "reserve" it for some > > period of time (and that is a SERVER implementation issue). In my server, > > I might chose that time to be 0 seconds. In your server, you can set it to > > 1 hour. The client can't do anything with ADVERTISEd information other than > > make a decision based on which ADVERTISE it wants to accept (assuming > it gets > > multiple). In any case, the information from the Reply is what it must > install. > > So, this is purely a server implementation issue. > >VB2> Yes. I agree that this is purely an implementation issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 20:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29537; Mon, 21 Jan 2002 20:28:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05485; Mon, 21 Jan 2002 20:27:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05460 for ; Mon, 21 Jan 2002 20:27:13 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29533 for ; Mon, 21 Jan 2002 20:27:09 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA16485; Mon, 21 Jan 2002 20:27:04 -0500 Date: Mon, 21 Jan 2002 20:27:04 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <4.3.2.7.2.20020121141605.032339d8@funnel.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph, I believe the IETF wants to move to SLP for this. I think we need to check. I just don't want to build competing functions. If we do it fine but I think this requires some discussions iwth SLP folks too. /jim On Mon, 21 Jan 2002, Ralph Droms wrote: > We've taken an "on-demand" approach to adding options to DHCPv6 - that is, > as options are requested, we've added them. There hasn't been any > intentional oversight; to avoid carrying forward unnecessary options (e.g., > "Impress server"), we've simply started with a clean (or almost clean) > slate. 'bootfile' and 'TFTP server' seem like good candidates for > inclusion in DHCPv6. > > For WG discussion - should the 'bootfile' and 'TFTP server' options be > carried over verbatim to DHCPv6 or are there changes that should be made? > > - Ralph > > At 12:22 AM 1/21/2002 +0000, Michael Johnston wrote: > >There is no bootfile or TFTP server information in the DHCPv6 > >draft. Maybe this is intentional. Is there another mechanism that is to > >be used by network boot clients to locate image servers and download images? > > > >%%michael > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 21 20:48:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29749; Mon, 21 Jan 2002 20:48:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06206; Mon, 21 Jan 2002 20:47:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06169 for ; Mon, 21 Jan 2002 20:47:57 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29743 for ; Mon, 21 Jan 2002 20:47:53 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0M1lQS10773 for ; Mon, 21 Jan 2002 19:47:26 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0M1lPD11323 for ; Mon, 21 Jan 2002 19:47:26 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Jan 21 19:47:25 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 19:47:25 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDDB@EAMBUNT705> From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Cc: "'Jun-ichiro itojun Hagino '" Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments Date: Mon, 21 Jan 2002 19:47:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A2E6.BD0D7C80" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A2E6.BD0D7C80 Content-Type: text/plain; charset="iso-8859-1" Sorry, forgot to include the main list on this issue so resending. -----Original Message----- From: Bernie Volz (EUD) Sent: Monday, January 21, 2002 8:46 PM To: 'Jun-ichiro itojun Hagino' Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments Itojun: Is this really a major concern for you? We aren't asking that much of the client - we already ask it to retransmit messages and keep this much state, is asking it to ignore additional Reconfigure messages really that much state to keep? It doesn't have to remember this state if it crashes or is shutdown (since it should do an Inform when it starts to make sure its current configuration is accurate). In fact, we might want to add some text to the draft (if it isn't already there) that a client that has used Inform should re-Inform when it detects that it may have moved to a new link (ie, send an Inform when a Confirm was to have been used if the client obtained addresses). - Bernie -----[Modified] Original Message----- From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] Sent: Wednesday, December 26, 2001 3:54 AM To: rdroms@cisco.com Cc: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments (text cut) 4. As far as I understand the goal of Inform message is to make it possible to make it possible to implement a stateless client which obtains various information from DHCPv6 server (draft-droms-dnsconfig-dhcpv6-00.txt). My question - does it make you any trouble if there's a client implementation that does not understand Reconfigure message? If we try to support Reconfigure (Inform solicited by DHCP server) client implementation becomes stateful. Also, it would have been easier if Inform message does not mandate DUID... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A2E6.BD0D7C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments

Sorry, forgot to include the main list on this issue = so resending.

-----Original Message-----
From: Bernie Volz (EUD)
Sent: Monday, January 21, 2002 8:46 PM
To: 'Jun-ichiro itojun Hagino'
Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt = comments


Itojun:

Is this really a major concern for you? We aren't = asking that much of the client - we already ask it to retransmit = messages and keep this much state, is asking it to ignore additional = Reconfigure messages really that much state to keep?

It doesn't have to remember this state if it crashes = or is shutdown (since it should do an Inform when it starts to make = sure its current configuration is accurate).

In fact, we might want to add some text to the draft = (if it isn't already there) that a client that has used Inform should = re-Inform when it detects that it may have moved to a new link (ie, = send an Inform when a Confirm was to have been used if the client = obtained addresses).

- Bernie

-----[Modified] Original Message-----
From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net]
Sent: Wednesday, December 26, 2001 3:54 AM
To: rdroms@cisco.com
Cc: dhcwg@ietf.org
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt = comments

(text cut)

4.
As far as I understand the goal of Inform message is = to make it possible
to make it possible to implement a stateless client = which obtains various
information from DHCPv6 server = (draft-droms-dnsconfig-dhcpv6-00.txt).
My question - does it make you any trouble if = there's a client implementation
that does not understand Reconfigure message?  = If we try to support
Reconfigure (Inform solicited by DHCP server) client = implementation becomes
stateful.  Also, it would have been easier if = Inform message does not mandate
DUID...

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A2E6.BD0D7C80-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 03:36:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13783; Tue, 22 Jan 2002 03:36:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26746; Tue, 22 Jan 2002 03:36:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26721 for ; Tue, 22 Jan 2002 03:36:07 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13770 for ; Tue, 22 Jan 2002 03:36:04 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23334; Tue, 22 Jan 2002 01:36:05 -0700 (MST) Received: from sun.com (vpn-129-159-0-15.EMEA.Sun.COM [129.159.0.15]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id JAA02926; Tue, 22 Jan 2002 09:36:03 +0100 (MET) Message-ID: <3C4D2411.1000908@sun.com> Date: Tue, 22 Jan 2002 09:34:25 +0100 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jim Bound CC: Ralph Droms , dhcwg Subject: Re: [dhcwg] Am I missing something? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Jim, > I believe the IETF wants to move to SLP for this. I think we need to > check. I just don't want to build competing functions. If we do it > fine but I think this requires some discussions iwth SLP folks too. I must admit it's hard for me to conceive of DHCP without boot parameter options. I guess I'm showing my age. SLP is great for discoving 'differentiated' services - that is services which are not generic. Boot images that can be found by look-up-by-name are generic. This does require that DHCP servers be configured to know about TFTP servers and their contents, but in practice, this has worked out fairly well. Boot images which require multiple round trips between client and server (as per PXE) are NOT generic and would be better discovered via SLP. [Aside: PXE uses a hacked set of non- standard DHCP messages to perform iterative queries to configure a client to boot.] Further examples of non-generic services include, say, peer to peer file sharing services. There is no standard way to update the DHCP server dynamically, to know which service are available on the network, or what (characteristics) differentiates them. Clients seeking non-generic services don't want *just any* file server, they want the file server with the name, description, access permissions, etc. that they are seeking. This is a great application for SLP and an inappropriate one for DHCP. Ralph, >>We've taken an "on-demand" approach to adding options to DHCPv6 - that is, >>as options are requested, we've added them. There hasn't been any >>intentional oversight; to avoid carrying forward unnecessary options (e.g., >>"Impress server"), we've simply started with a clean (or almost clean) >>slate. 'bootfile' and 'TFTP server' seem like good candidates for >>inclusion in DHCPv6. I would like to see option 78 and 79 for DHCPv6 as well (SLPv2 DA and SLPv2 scope list options.) We are revising RFC2610 as part of bringing SLPv2 to draft standard. I guess we should include a description of the DHCPv6 options there as well? Are there any examples of how to do that? How do you suggest we proceed? Thanks, Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 05:28:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15055; Tue, 22 Jan 2002 05:28:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00585; Tue, 22 Jan 2002 05:24:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00564 for ; Tue, 22 Jan 2002 05:24:32 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14999 for ; Tue, 22 Jan 2002 05:24:28 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-61.cisco.com [10.82.240.61]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA01521; Tue, 22 Jan 2002 05:24:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020122050446.036870b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 05:24:27 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Issues raised during last call for DHCPv6 specification Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today. - Ralph Droms Open issues ----------- * We've experienced a proliferation of DHCPv6 options. Should all options *not* used in the base protocol be moved out to separate drafts? * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Other options: - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Should the Decline message have error codes defining the reason for the Decline? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. * Do we want to allow a client to request that more normal addresses be added to an IA, perhaps through use of the equivalent of the RTA option? * DHCP/DDNS interaction * Is the text in section 17.1.3 sufficient? Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - In the list of DHCP messages in section 7, fix Reconfigure to start Renew/Reply or Inform/Reply sequence (not Request/Reply) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix redundancy between sections 18.2.5 and 18.2.8 - Edit third paragraph of section 19.2 to delete references to IAs - In section 19.3.4, change "Rebind or Information-Request" to "Renew or Information-Request" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". - Edit section 22.14 to indicate that the server-address field is in the fixed-format part of the DHCP message, not the unicast option - Clarify the text in section 22.19 to indicate that the 'user class data' items are carried in the data area of the 'user class option' * Clarify text in section 13 about address selection based on source of message from client * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option * Modify SIP server option according to input from Henning Schulzrinne * Require that the DUID option appear before any IA options to improve processing efficiency * Require that the authentication option be first in th elist of options to reduce the work that a server must expend before discarding a message that fails authentication (reduces effect of denial of service attacks) * Clean up text specifying selection of address by server to insert into 'server-address' field * Clarify that a server MAY return fewer temporary addresses than requested by the client and MUST return AddrUnavail only if no temporary addresses are available * Clarify that a client MUST include all requested options in an ORO and MAY include suggested values by including specific options; also, the server MAY ignore suggestions from client and the client MUST use whatever the server returns * Clarify that a server MAY renew only some of the IAs sent by a client * Change DUID/VUID to have a length field to allow for longer IDs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 10:43:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27162; Tue, 22 Jan 2002 10:43:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13938; Tue, 22 Jan 2002 10:41:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13890 for ; Tue, 22 Jan 2002 10:41:33 -0500 (EST) Received: from email2.byu.edu (email2.byu.edu [128.187.22.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27105 for ; Tue, 22 Jan 2002 10:41:29 -0500 (EST) Received: from tj ([128.187.7.248]) by EMAIL1.BYU.EDU (PMDF V6.0-24 #38579) with ESMTP id <01KDD68O9E8U8ZHUAW@EMAIL1.BYU.EDU> for dhcwg@ietf.org; Tue, 22 Jan 2002 08:40:58 -0700 (MST) Date: Tue, 22 Jan 2002 08:41:14 -0700 From: Terrance Humphries Subject: RE: [dhcwg] additional option for dhcpv6 In-reply-to: To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Please remove me from your list. Thanks, Terrance Humphries Network Security and Administration Manager Tjay@byu.edu 801-224-7513 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Vijay Bhaskar A K Sent: Sunday, January 20, 2002 7:34 AM To: mjs@cisco.com Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: [dhcwg] additional option for dhcpv6 Mark, Thanks for your thorough review. See my comments inline. ~ Vijay > 1) The FQDN option needs, I think, to look a lot like the FQDN option > for > dhcpv4. The option i defined here is, for just transfering the FQDN releated to temporary address. It is similar to hostname option in DHCPv4. I will rename it to hostname option. I feel like, since the DDNS updates are still TBD, we can define the FQDN option with appropriate fields needed later, once DDNS specs are finalised. > The name encoding must be specified. Yes. It is needed. I will add the appropriate text. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. For the temporary addresses, DNS update is done by server. So, these fields are not necessary. > > 2) The subnet-selection option text should not compel the server to > somehow > obey the client's suggestion. It should be explict that the server > administrator's configuration takes precedence, and that the client's > indication that it desires a specific subnet can only be a hint that's > considered along with all of the other information available to the server. This is the only way the client can tell its prefernce for the prefix. If the server is not supposed to allocate address for that prefix, then it wont. If the client is not very particular about the prefix, it should not use this option. This option will be more helpful in the network with two prefixes and the client wants a particular one. > > A nit: isn't the option-len sufficient to determine the prefix length? > Is > the prefix-len byte necessary? No, it is not sufficient. Without the prefix-len field, you cannot find out the exact prefix length. For example, you can identify whether the prefix length is between 57 and 64. You cannot find out the exact prefix length. > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > options should be DNS encoding, shouldn't it? That seems more robust than > ASCII to me. Agreed. > > 4) The 'Service Location Protocol Directory Agent Option' places the > 'typed-scope-list-len' field before the 'DA address', rather than before > the 'typed scope list'. Couldn't the length of the list immediately precede > the list? I think, it won't make any difference. Let me know, if there are any serious issues on this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 13:45:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04322; Tue, 22 Jan 2002 13:45:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03890; Tue, 22 Jan 2002 13:44:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03869 for ; Tue, 22 Jan 2002 13:44:50 -0500 (EST) Received: from NS1.US.PRSERV.NET ([64.180.246.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04276 for ; Tue, 22 Jan 2002 13:44:46 -0500 (EST) From: sydney@vkistudios.org Message-Id: <200201221844.NAA04276@ietf.org> Reply-To: seo@vkistudios.org To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 22 Jan 2002 10:48:20 -0800 Subject: [dhcwg] ADV: Professional Internet Marketing Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Professional Internet Marketing, VKI Studios 1-866-733-8899
1-866-733-8899 

 

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 14:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08177; Tue, 22 Jan 2002 14:57:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08685; Tue, 22 Jan 2002 14:55:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08650 for ; Tue, 22 Jan 2002 14:55:47 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08143 for ; Tue, 22 Jan 2002 14:55:43 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01054 for ; Tue, 22 Jan 2002 14:55:14 -0500 (EST) Message-Id: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 14:55:41 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Options in base doc for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org We've recently experienced a proliferation of proposed and defined options for DHCPv6. Initially, the WG agreed to publish all options that were defined at the time the base spec was completed in the same doc. I'm having second thoughts about that decision. Here's what I'm thinking: * The new options are adding more weight to an already hefty document * Keeping all the options in one doc make updating any one option more complicated * Reviewing all of these options will slow down the acceptance process I propose that we put a moratorium on adding any new options to draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of "essential" is open to discussion; here's a first pass at a list of the options to retain in draft-ietf-dhc-dhcpv6-22.txt: * DHCP unique identifier option * Identity association option * IA Address option * Requested Temporary Addresses (RTA) Option * Option request option * Preference option * Elapsed Time * Client message option * Server message option * Authentication option * Server unicast option * Domain Search Option * Domain Name Server Option * Status Code Option - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 15:11:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08670; Tue, 22 Jan 2002 15:11:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09566; Tue, 22 Jan 2002 15:11:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09546 for ; Tue, 22 Jan 2002 15:11:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08656 for ; Tue, 22 Jan 2002 15:10:57 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03276 for ; Tue, 22 Jan 2002 15:10:29 -0500 (EST) Message-Id: <4.3.2.7.2.20020122145946.036d26a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 15:10:55 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Two options proposed during WG last call Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org These two options were proposed during the WG last call on draft-ietf-dhc-dhcpv6-22.txt. - Default routes A default routes option is unnecessary because of neighbor discovery/router advertisements; is there some other reason to configure a host with default routes? - Static routes The static routes option has been discussed in the thread "static route option for dhcpv6". The summary of the discussion is that a static routes option might be useful to configure a host for tunnels. Please follow up with comments about whether we should define these two options for DHCPv6. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 15:24:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09019; Tue, 22 Jan 2002 15:24:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10817; Tue, 22 Jan 2002 15:23:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10796 for ; Tue, 22 Jan 2002 15:23:33 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09008 for ; Tue, 22 Jan 2002 15:23:29 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA04910; Tue, 22 Jan 2002 15:23:01 -0500 (EST) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-110.cisco.com [161.44.149.110]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM73107; Tue, 22 Jan 2002 15:23:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020122152250.025e3638@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 15:26:13 -0500 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] Options in base doc for DHCPv6 Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I think that this proposal makes a great deal of sense. I do think that the boot-file and tftp server address(es) options need to be added to the core list: they really are 'core' to the boot process. -- Mark At 02:55 PM 1/22/2002 -0500, Ralph Droms wrote: >We've recently experienced a proliferation of proposed and defined options >for DHCPv6. Initially, the WG agreed to publish all options that were >defined at the time the base spec was completed in the same doc. I'm >having second thoughts about that decision. Here's what I'm thinking: > >* The new options are adding more weight to > an already hefty document >* Keeping all the options in one doc make > updating any one option more complicated >* Reviewing all of these options will slow > down the acceptance process > >I propose that we put a moratorium on adding any new options to >draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of >draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of >"essential" is open to discussion; here's a first pass at a list of the >options to retain in draft-ietf-dhc-dhcpv6-22.txt: > >* DHCP unique identifier option >* Identity association option >* IA Address option >* Requested Temporary Addresses (RTA) Option >* Option request option >* Preference option >* Elapsed Time >* Client message option >* Server message option >* Authentication option >* Server unicast option >* Domain Search Option >* Domain Name Server Option >* Status Code Option > >- Ralph > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 16:10:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10439; Tue, 22 Jan 2002 16:10:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12161; Tue, 22 Jan 2002 15:56:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12135 for ; Tue, 22 Jan 2002 15:56:41 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10017 for ; Tue, 22 Jan 2002 15:56:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09696 for ; Tue, 22 Jan 2002 13:56:32 -0700 (MST) Received: from gullwing.eng.sun.com (gullwing.Eng.Sun.COM [129.146.111.80]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20449 for ; Tue, 22 Jan 2002 12:56:32 -0800 (PST) Received: from gullwing (gullwing [129.146.111.80]) by gullwing.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id g0MKuUD06061 for ; Tue, 22 Jan 2002 12:56:30 -0800 (PST) Message-Id: <200201222056.g0MKuUD06061@gullwing.eng.sun.com> Date: Tue, 22 Jan 2002 12:56:30 -0800 (PST) From: Warren Belfer Reply-To: Warren Belfer Subject: Re: [dhcwg] Two options proposed during WG last call To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BMdQUZFPrPiPQ5NPv76XoQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >- Default routes > >A default routes option is unnecessary because of neighbor discovery/router >advertisements; is there some other reason to configure a host with default >routes? Yes; for security reasons; I (and others, I presume) do not want hosts responding to spurious routing information. My routers do not advertise routes (neither RIP nor router discovery) and my clients don't listen for them. warren Warren Belfer Lead Operations Engineer Internet Services Engineering Sun Microsystems, Inc. >- Static routes > >The static routes option has been discussed in the thread "static route >option for dhcpv6". The summary of the discussion is that a static routes >option might be useful to configure a host for tunnels. > >Please follow up with comments about whether we should define these two >options for DHCPv6. > >- Ralph > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 19:27:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15336; Tue, 22 Jan 2002 19:27:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19418; Tue, 22 Jan 2002 19:26:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19401 for ; Tue, 22 Jan 2002 19:26:34 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15321 for ; Tue, 22 Jan 2002 19:26:31 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13524; Tue, 22 Jan 2002 19:25:06 -0500 Date: Tue, 22 Jan 2002 19:25:06 -0500 (EST) From: Jim Bound To: Erik Guttman Cc: Ralph Droms , dhcwg Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <3C4D2411.1000908@sun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Eric, Yourone of the tech leads for SLP and first driver in the IETF for this so thats fine with me. ACK. Lets put it in DHC6 then. /jim On Tue, 22 Jan 2002, Erik Guttman wrote: > > Jim, > > > I believe the IETF wants to move to SLP for this. I think we need to > > check. I just don't want to build competing functions. If we do it > > fine but I think this requires some discussions iwth SLP folks too. > > I must admit it's hard for me to conceive of DHCP without boot > parameter options. I guess I'm showing my age. > > SLP is great for discoving 'differentiated' services - that is > services which are not generic. Boot images that can be found > by look-up-by-name are generic. This does require that DHCP > servers be configured to know about TFTP servers and their > contents, but in practice, this has worked out fairly well. > > Boot images which require multiple round trips between client > and server (as per PXE) are NOT generic and would be better > discovered via SLP. [Aside: PXE uses a hacked set of non- > standard DHCP messages to perform iterative queries to > configure a client to boot.] > > Further examples of non-generic services include, say, peer to > peer file sharing services. There is no standard way to update > the DHCP server dynamically, to know which service are available > on the network, or what (characteristics) differentiates them. > Clients seeking non-generic services don't want *just any* file > server, they want the file server with the name, description, > access permissions, etc. that they are seeking. This is a great > application for SLP and an inappropriate one for DHCP. > > Ralph, > > >>We've taken an "on-demand" approach to adding options to DHCPv6 - that is, > >>as options are requested, we've added them. There hasn't been any > >>intentional oversight; to avoid carrying forward unnecessary options (e.g., > >>"Impress server"), we've simply started with a clean (or almost clean) > >>slate. 'bootfile' and 'TFTP server' seem like good candidates for > >>inclusion in DHCPv6. > > I would like to see option 78 and 79 for DHCPv6 as well (SLPv2 DA > and SLPv2 scope list options.) We are revising RFC2610 as part of > bringing SLPv2 to draft standard. I guess we should include a > description of the DHCPv6 options there as well? Are there any > examples of how to do that? How do you suggest we proceed? > > Thanks, > > Erik > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 19:41:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15570; Tue, 22 Jan 2002 19:41:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20081; Tue, 22 Jan 2002 19:40:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20058 for ; Tue, 22 Jan 2002 19:40:08 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15549 for ; Tue, 22 Jan 2002 19:40:03 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA16493; Tue, 22 Jan 2002 19:40:03 -0500 Date: Tue, 22 Jan 2002 19:40:03 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org We require the IPv6 options for IPv6 Transition now. /jim On Tue, 22 Jan 2002, Ralph Droms wrote: > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 19:57:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15906; Tue, 22 Jan 2002 19:57:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20444; Tue, 22 Jan 2002 19:56:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20419 for ; Tue, 22 Jan 2002 19:56:14 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15867 for ; Tue, 22 Jan 2002 19:56:11 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11518; Tue, 22 Jan 2002 19:56:09 -0500 Date: Tue, 22 Jan 2002 19:56:09 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Two options proposed during WG last call In-Reply-To: <4.3.2.7.2.20020122145946.036d26a0@funnel.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph, An essential option set for dhc6 is that which will assist with the deployment of IPv6 immediately. That is the case for configured tunnels. Right now I am not convinced that we should add default routes to clients for dhc6. Not because they are learned (provided is not the case) by ND, as I believe the Dentist Office Scenario may justify them or a Home IPv6 Gateway box that wants to provide them instead of the router because it is not running full routing protocol to learn all routes. In this case my ISP tells me my static route and I configure that with DHC6. The reason for not doing it now is it requires more analysis and discussion than I think we should do before final last call and to PS process. I will argue that wee should permit this but it will take a long time to discuss. So in the interest of moving forward I suggest we not include default routes for now. /jim On Tue, 22 Jan 2002, Ralph Droms wrote: > These two options were proposed during the WG last call on > draft-ietf-dhc-dhcpv6-22.txt. > > - Default routes > > A default routes option is unnecessary because of neighbor discovery/router > advertisements; is there some other reason to configure a host with default > routes? > > - Static routes > > The static routes option has been discussed in the thread "static route > option for dhcpv6". The summary of the discussion is that a static routes > option might be useful to configure a host for tunnels. > > Please follow up with comments about whether we should define these two > options for DHCPv6. > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 20:22:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16495; Tue, 22 Jan 2002 20:22:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21258; Tue, 22 Jan 2002 20:21:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21235 for ; Tue, 22 Jan 2002 20:21:28 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16470 for ; Tue, 22 Jan 2002 20:21:25 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0N1LRh29312 for ; Tue, 22 Jan 2002 19:21:27 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0N1LRJ29478 for ; Tue, 22 Jan 2002 19:21:27 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Jan 22 19:21:27 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 19:21:26 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69BC7758@EAMBUNT705> From: "Bernie Volz (EUD)" To: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Two options proposed during WG last call Date: Tue, 22 Jan 2002 19:21:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3AC.45085180" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A3AC.45085180 Content-Type: text/plain; charset="iso-8859-1" Ralph: I don't see these as required for protocol operation and therefore would recommend (per your other message) to put them in a separate document. Also, these are probably not critical options as they deal with cases that will hopefully only exist in very few environments. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 3:11 PM To: dhcwg@ietf.org Subject: [dhcwg] Two options proposed during WG last call These two options were proposed during the WG last call on draft-ietf-dhc-dhcpv6-22.txt. - Default routes A default routes option is unnecessary because of neighbor discovery/router advertisements; is there some other reason to configure a host with default routes? - Static routes The static routes option has been discussed in the thread "static route option for dhcpv6". The summary of the discussion is that a static routes option might be useful to configure a host for tunnels. Please follow up with comments about whether we should define these two options for DHCPv6. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3AC.45085180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Two options proposed during WG last call

Ralph:

I don't see these as required for protocol operation = and therefore would recommend (per your other message) to put them in a = separate document. Also, these are probably not critical options as = they deal with cases that will hopefully only exist in very few = environments.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 3:11 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Two options proposed during WG last = call


These two options were proposed during the WG last = call on
draft-ietf-dhc-dhcpv6-22.txt.

- Default routes

A default routes option is unnecessary because of = neighbor discovery/router
advertisements; is there some other reason to = configure a host with default
routes?

- Static routes

The static routes option has been discussed in the = thread "static route
option for dhcpv6".  The summary of the = discussion is that a static routes
option might be useful to configure a host for = tunnels.

Please follow up with comments about whether we = should define these two
options for DHCPv6.

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A3AC.45085180-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 20:22:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16543; Tue, 22 Jan 2002 20:22:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21301; Tue, 22 Jan 2002 20:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21282 for ; Tue, 22 Jan 2002 20:21:56 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16478 for ; Tue, 22 Jan 2002 20:21:52 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0N1LOS07907 for ; Tue, 22 Jan 2002 19:21:24 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0N1LO717097 for ; Tue, 22 Jan 2002 19:21:24 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jan 22 19:21:23 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 19:21:23 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69BC7757@EAMBUNT705> From: "Bernie Volz (EUD)" To: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 Date: Tue, 22 Jan 2002 19:21:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3AC.44E22BE0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A3AC.44E22BE0 Content-Type: text/plain; charset="iso-8859-1" Ralph: I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 2:56 PM To: dhcwg@ietf.org Subject: [dhcwg] Options in base doc for DHCPv6 We've recently experienced a proliferation of proposed and defined options for DHCPv6. Initially, the WG agreed to publish all options that were defined at the time the base spec was completed in the same doc. I'm having second thoughts about that decision. Here's what I'm thinking: * The new options are adding more weight to an already hefty document * Keeping all the options in one doc make updating any one option more complicated * Reviewing all of these options will slow down the acceptance process I propose that we put a moratorium on adding any new options to draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of "essential" is open to discussion; here's a first pass at a list of the options to retain in draft-ietf-dhc-dhcpv6-22.txt: * DHCP unique identifier option * Identity association option * IA Address option * Requested Temporary Addresses (RTA) Option * Option request option * Preference option * Elapsed Time * Client message option * Server message option * Authentication option * Server unicast option * Domain Search Option * Domain Name Server Option * Status Code Option - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3AC.44E22BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options in base doc for DHCPv6

Ralph:

I agree with this. It also means we can divide the = work by having many people write drafts. Reviewing is also easier as = people can focus on those documents that they feel are critical to = them.

I also think your initial list of options looks good = and is the basic set for protocol operation. It may not provide the = basic set for client configuration and we might even argue that two, = the Domain Search Option and Domain Name Server Option, could even be = moved to that other document since they aren't related to the = operational issues of the DHCP protocol.

For IESG review, I think it will be important to = point out that this is the basic set required for proper DHCP protocol = operation and not the basic set to provide client = configuration.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 2:56 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Options in base doc for = DHCPv6


We've recently experienced a proliferation of = proposed and defined options
for DHCPv6.  Initially, the WG agreed to = publish all options that were
defined at the time the base spec was completed in = the same doc.  I'm
having second thoughts about that decision.  = Here's what I'm thinking:

* The new options are adding more weight to
   an already hefty document
* Keeping all the options in one doc make
   updating any one option more = complicated
* Reviewing all of these options will slow
   down the acceptance process

I propose that we put a moratorium on adding any new = options to
draft-ietf-dhc-dhcpv6-22.txt, and move any = non-essential options out of
draft-ietf-dhc-dhcpv6-22.txt into individual = drafts.  The definition of
"essential" is open to discussion; here's = a first pass at a list of the
options to retain in = draft-ietf-dhc-dhcpv6-22.txt:

* DHCP unique identifier option
* Identity association option
* IA Address option
* Requested Temporary Addresses (RTA) Option
* Option request option
* Preference option
* Elapsed Time
* Client message option
* Server message option
* Authentication option
* Server unicast option
* Domain Search Option
* Domain Name Server Option
* Status Code Option

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A3AC.44E22BE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 21:39:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18645; Tue, 22 Jan 2002 21:39:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24279; Tue, 22 Jan 2002 21:36:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24201 for ; Tue, 22 Jan 2002 21:36:54 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18609 for ; Tue, 22 Jan 2002 21:36:50 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-594.cisco.com [10.82.242.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA06580 for ; Tue, 22 Jan 2002 21:36:22 -0500 (EST) Message-Id: <4.3.2.7.2.20020122212127.03678058@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 21:36:48 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Other options for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Included below is a list of other options that are currently in draft-ietf-dhc-dhcpv6-22.txt or have been suggested for definition for DHCPv6. I propose that the WG agree on the list of additional options and that these options be documented individually or in small groups of related options (e.g., DSTM Global IPv4 Address Option and DSTM Tunnel EndPoint Option). I'll volunteer to extract the options that are currently in draft-ietf-dhc-dhcpv6-22.txt and generate separate docs for each; those options should get through process quickly. Your favorite option will get in the process a lot faster if you volunteer to write a draft for it... - Bootfile name - TFTP server - DSTM Global IPv4 Address Option - DSTM Tunnel EndPoint Option - Circuit-ID Option - User Class Option - Vendor Class Option - SIP Servers Domain Name List - SIP Servers IPv6 Address List - FQDN - Static routes - Default routes - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 21:50:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18835; Tue, 22 Jan 2002 21:50:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25081; Tue, 22 Jan 2002 21:50:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25056 for ; Tue, 22 Jan 2002 21:50:02 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18821 for ; Tue, 22 Jan 2002 21:49:58 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-594.cisco.com [10.82.242.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA07144 for ; Tue, 22 Jan 2002 21:49:30 -0500 (EST) Message-Id: <4.3.2.7.2.20020122213702.03702ea0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 21:49:56 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Assigning DHCPv6 option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org There is a potential collision problem between DHCPv4 and DHCPv6 option codes. The DHCID RR uses the option code to identify the source of the information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option codes that identify different options, the source of the information in the RR will be ambiguous. One proposed solution is to start numbering DHCPv6 options at 256, to avoid collisions with DHCPv4 option codes. Another solution is to assign new codes for the identification field in the DHCID RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other sources of information not encoded in a DHCP option. For example, DHCID RR code 1 might identify the contents of the RR as a DHCPv4 client identifier, while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two solutions? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 23:41:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21701; Tue, 22 Jan 2002 23:41:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28455; Tue, 22 Jan 2002 23:40:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28423 for ; Tue, 22 Jan 2002 23:40:43 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21668 for ; Tue, 22 Jan 2002 23:40:38 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13444; Tue, 22 Jan 2002 23:40:37 -0500 Date: Tue, 22 Jan 2002 23:40:37 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69BC7757@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, Again DNS options are needed NOW for IPv6 deployment. Specifically for IPv6 DNS Stateless discovery. That which is needed for IPv6 deployment is as important to any option we have in the spec. Implementors like VJ and others need these now the reason is we are so late with DHC6 for the market we do not have the luxury to not include basic options which which are required by the IPv6 market early adopters. So I would argue this should affect our thinking on this discussion. Right now boot server for diskess nodes is less important to the market (our customer here) than configured tunnel option. /jim On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote: > Ralph: > > I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. > > I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. > > For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, January 22, 2002 2:56 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Options in base doc for DHCPv6 > > > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 22 23:43:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21763; Tue, 22 Jan 2002 23:43:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28508; Tue, 22 Jan 2002 23:42:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28479 for ; Tue, 22 Jan 2002 23:42:49 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21728 for ; Tue, 22 Jan 2002 23:42:44 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06053; Tue, 22 Jan 2002 23:42:45 -0500 Date: Tue, 22 Jan 2002 23:42:45 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Other options for DHCPv6 In-Reply-To: <4.3.2.7.2.20020122212127.03678058@funnel.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org SIP is on that needed deployment list too. The Telcos want it follks for SIP phones and multimedia. /jim On Tue, 22 Jan 2002, Ralph Droms wrote: > Included below is a list of other options that are currently in > draft-ietf-dhc-dhcpv6-22.txt or have been suggested for definition for DHCPv6. > > I propose that the WG agree on the list of additional options and that > these options be documented individually or in small groups of related > options (e.g., DSTM Global IPv4 Address Option and DSTM Tunnel EndPoint > Option). I'll volunteer to extract the options that are currently in > draft-ietf-dhc-dhcpv6-22.txt and generate separate docs for each; those > options should get through process quickly. Your favorite option will get > in the process a lot faster if you volunteer to write a draft for it... > > - Bootfile name > - TFTP server > - DSTM Global IPv4 Address Option > - DSTM Tunnel EndPoint Option > - Circuit-ID Option > - User Class Option > - Vendor Class Option > - SIP Servers Domain Name List > - SIP Servers IPv6 Address List > - FQDN > - Static routes > - Default routes > - NTP servers > - NIS servers > - NIS+ servers > - Subnet selection > - NIS domain name > - NIS+ domain name > - IEEE 1003.1 POSIX timezone > - SLP directory agent > - SLP service scope > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 01:46:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23582; Wed, 23 Jan 2002 01:46:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10579; Wed, 23 Jan 2002 01:42:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10555 for ; Wed, 23 Jan 2002 01:42:13 -0500 (EST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23541 for ; Wed, 23 Jan 2002 01:42:12 -0500 (EST) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel10.hp.com (Postfix) with ESMTP id A8404C0018E; Tue, 22 Jan 2002 22:41:40 -0800 (PST) Received: (from jitesh@localhost) by chitha.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id LAA15347; Wed, 23 Jan 2002 11:55:35 +0530 (IST) From: Jitesh N Verma Message-Id: <200201230625.LAA15347@chitha.india.hp.com> Subject: Re: [dhcwg] Options in base doc for DHCPv6 To: mjs@cisco.com Date: Wed, 23 Jan 2002 11:55:34 +0530 (IST) Cc: rdroms@cisco.com, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020122152250.025e3638@goblet.cisco.com> from Mark Stapp at Jan "22," 2002 "03:26:13" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi List, I strongly agree with Mark. Booting mechanism belongs to DHCP domain. Regards, Jitesh > I think that this proposal makes a great deal of sense. I do think that the > boot-file and tftp server address(es) options need to be added to the core > list: they really are 'core' to the boot process. > > -- Mark > > At 02:55 PM 1/22/2002 -0500, Ralph Droms wrote: > >We've recently experienced a proliferation of proposed and defined options > >for DHCPv6. Initially, the WG agreed to publish all options that were > >defined at the time the base spec was completed in the same doc. I'm > >having second thoughts about that decision. Here's what I'm thinking: > > > >* The new options are adding more weight to > > an already hefty document > >* Keeping all the options in one doc make > > updating any one option more complicated > >* Reviewing all of these options will slow > > down the acceptance process > > > >I propose that we put a moratorium on adding any new options to > >draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > >draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > >"essential" is open to discussion; here's a first pass at a list of the > >options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > > >* DHCP unique identifier option > >* Identity association option > >* IA Address option > >* Requested Temporary Addresses (RTA) Option > >* Option request option > >* Preference option > >* Elapsed Time > >* Client message option > >* Server message option > >* Authentication option > >* Server unicast option > >* Domain Search Option > >* Domain Name Server Option > >* Status Code Option > > > >- Ralph > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 02:04:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28457; Wed, 23 Jan 2002 02:04:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11302; Wed, 23 Jan 2002 02:03:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11218 for ; Wed, 23 Jan 2002 02:03:07 -0500 (EST) Received: from e3500.vnn.vn (e3500.vnn.vn [203.162.0.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26917 for ; Wed, 23 Jan 2002 02:02:48 -0500 (EST) Date: Wed, 23 Jan 2002 02:02:48 -0500 (EST) Message-Id: <200201230702.CAA26917@ietf.org> Received: from aol.com ([203.162.12.241]) by e3500.vnn.vn (Netscape Messaging Server 4.15 e3500 Sep 28 2000 18:20:45) with SMTP id GQDQ9G00.EWA for ; Wed, 23 Jan 2002 14:03:16 +0700 From: "cao hai van" <_hndelta@hn.vnn.vn> To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="====_ABC1234567890DEF_====" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 Subject: [dhcwg] Re: Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --====_ABC1234567890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC0987654321DEF_====" --====_ABC0987654321DEF_==== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --====_ABC0987654321DEF_====-- --====_ABC1234567890DEF_==== Content-Type: audio/x-wav; name="fun.MP3.pif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAoxs1SbKejAWynowFsp6MBF7uvAWinowHvu60BbqejAYS4qQF2p6MBhLin AW6nowEOuLABZaejAWynogHyp6MBhLioAWCnowHUoaUBbaejAVJpY2hsp6MBAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUEUAAEwBAwCoIP47AAAAAAAAAADgAA8BCwEGAABwAAAAEAAAANAAAEBHAQAA 4AAAAFABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQ AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkUAEAMAEAAABQAQBkAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAEAAAAAAAAAAEAAAA AAAAAAAAAAAAAACAAADgAAAAAAAAAAAAcAAAAOAAAABqAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5y c3JjAAAAABAAAABQAQAAAgAAAG4AAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAkCCN1hYc1ltHkUdCgBADdnAAAAEAEAJgEAve3/ //9Vi+wPvkUIi8iD4APB+QLB4ASKiWiiQACITQgX3bH//00Mi9GD4Q/B+gQLwsHhAoqAGUUJMRDB Ztvbi9AWBgvKNj8wHB1ht9tNCh8Li1Bdw1nGMhdLth89XVpiWnYoO3uKBI0JCkQKPXH9Yc8dCDZU MFGDfQwB3ZtmuxD8PQP9/v89dQ4eirbf3f8AUOgBAACbWcnDIwJ1EhNIARZR7MjNxxdWWevlA3wY AlEbR27tP9f+//+DxAw1YvzJUVO/ffv/i10MVlcz9jP/hdt+WxcQagOJHI1DAjPS2Hdf+Fn38Yld H/jB5wJH/3UQA8Zey/Zv28wg+KoMikX6iGUNCA77vdvebgUPjRFqBFAl/CI/6oNt9v/2ti2DRwSD xgbEFDvzfL2Lx19eW3T+v739ikQkBDzFAwQDCsiA4XCA+WB8AyxHw/+XptkHQEEwBATDPCsPlcCD wBd+c78+pYpNbMjRwOACwGcKwnm7Ff6LVRjA4QSIx62K0BECCsoJX/htHBwGCkUUiG5NIIgBP7C2 bbaMCAGkBwygCiLLYO4QugoUEHXNdtm+FP1QA/7/xBTt9mDOJzVA1bBAxCw4Qltoy9t0OAQMdDMQ GxIYl63Ntn//agGICOsfEBQODASt0P3C/ohtdQRqAusL/U0N+C+02wJY9jPAA2X/OXwkDH48i+3v /l8DCFNWav5bjXACK9gNGAPHUIpGAQMofOi6Bgb/A/5oAgw9Cm9vWCb4P40EMzslFHzUQT+42xtG w1aLdEZW/wRr8FlQvg3/cwrIAp+AJDAA4F7DHQiz79tFKxBWIRTKLyH7zfDDEF4ggewYzvEIiU38 UMnf+G13agDvaAIRgP8VAKCRhcAPhXb78tunAA5WV74UwI196KUr+McCDR0X3AA1KIXoTaUw9MzW bXcD6GalPlA/pDskW9i4Fes9dWSE9ApeKbfl1j1oEENQHQyhWRxZdGyzvfcIgKQFGHU0GIC9Dzs2 dnZ0KDFQv0AG/Iuiezf2fYkBjY0XURH2xbAB6ws9uW8XJjJiwgSsi/FoZGkP273dIgMthIMoaDAN i84PGGpw7PexEE/HBCQgkIkGTFlZ4Yb5zTM6gz4AdQWA/zZfW/ruDRtYi8GDIAA4Abq6f/h3dAeA QAJZw8gPt0gMUQQK3BeeeQgD8/80jaxfdnN76woGA0AEUQ+FlGg4wQTfZha6WSQIFMMkRAT9W5va i0xIhf8rH/8CdA5mixA23v6/AjQBZjvWdw9yEkdAQBUIcuVDXwzfuNCkpljrEsj/6/PAf7t1FBRH V191GgNBDgPwv+h9+0vbAwCoxrqL32o89/MJZolRDpbbir0N9/dfEg7wJxe6Xyu7BUUYHiKL9yQM Q36fa/YjGRYfQQrI2O10QgoDX1cfFOl0y8gI914+CINTx1ttDLSKadJtHgOkLb19ew5r0h4HZgNB BgPwdFsRX7bpfrsfUQI7wivHdBoDEg6Dsn777e50CQgFah/YD2oe6/nmZjkBD5SF/9+a/Bwr3jvD cx1mg/oMdQtm/xDt7e7tx0ECXOsFQnMCZitUBuusCm1zRtdxBlld0AAzyUK9gRdofU2AQO/OFBFB O7vdCm8/iJQFdgByAhxAPSQd+63wct05tVcyyYqCJpwV7/f/+x+NsgwC2ALLQg+2+YqfDYH6L3dr 99+NvwuIHqJC8AYHcrslQAl9xzpbAAZB2/4FElPc3u+3OQ0HipExABUfEgVBrc/v85iNgAWImVuI wi+2e+/CAoEKWSjAih7OwUuv4YPsDN5oflxoRPDL5XL7LvR6A/Vy9h33pfh9XC6X8vmj+sn7sZcI 1wI/NpFqCKIF/twIPkt/YwN5MzZGXzv3diO9/A42KH1H/02gH+H2b2p3JQaAMgdeiAQ5Rzv+cufK RmpqLndyyqGzIL/BzWYFHGoWmRb5i/LB5u7HR/oD/7YIxWcGzYs9zLu4DyHbGGOmU+HXIQzBbWWy FjiRKGOvXHOrPAQEH/z7AQpyv84Gegz/u0Ieu93cHVxufRVaaAimib0M4N0Dl55RQCrsDADkVg1Q Yz1rtU0iwTVUCF1dBVO7exEOU16LT+zUtnMbXchqYAFhFksz8SHd1t0UXoP4/1Z1YQgO7A/yCCTG 9kYDD3QqGhAddmBDFPCRXmCiHLuSEADVEAZKuXWg1USAMyDQ9P3tycCAZ1UH8YsYGOvu5428BYuF +AXB6BDZlmDm1mSM1Ng0AP47XXPuvzKujbQFBBN1BGLD7gWzgUujjJvbD4OTB6M0O3s6MFYxefG5 eINSpEgKiigF4AilL0n5D3VuHmyKJvZyK+xzRolTMPD5RlBWOTcTQ3hXUHzoYHwpZreSiWb+kydz FylopQgYaUTyE0J7qxUcJAt1+OkPCRjykIUrEBA8M5zd8E+ruOCTEDwffbhZMLyDZfwAIPzkiWXw thkeaBzseT8hxewXoYGfYSqMCITpN8hbQOBW8EYEfx3oQesGBiIOiR9bA9OTHLgYGkYVTPTQ0blv gmSJDQAAiQgGQJMbFDjb7YzooDwMXth1K1lqICRQxkJtBs5WCU1avb8G3w08QFEqCZ1eUHYD7a9K uV2DZtcQw7j06mDP3R1RGol18FzuYMx9zTGDCUI1Y5+euWBOOsn1IEHwnOTIkZsG9Ij4dPxokSO3 buAsgAbkAegChFuJzewDM9unbzdWGDEYiULRHThp9OC3uxB+EEOD04P7BHzdTCB2W9rni/PJAtA1 8C/FJw3vT41ECAHfDEQ14CycxthO69TVVEIzREs0cN3/NTSjDtqsZjM4PLAk0RFGn87WeHU8wHVU XjnXY+NqRBuskp9RL5b70SX9xqxEyOAxXnOtuUBZJrUqDgBz3azNTDYuYTwhKFywSqY4bUE8P9+v LVvjoFCgf/xo5OzwGesIggrDDTJoP8VYBCteH6v8731um+Yq6zwNENkIXoRZshhIm0WdzWzLxghM ZgxITUiGwWaSkQwnSRsvsWyH3Fk7x2gFLfb2h7isjU34UQP8UVeTBaEDY91I8VKNMlFvfRDqbgaa 9gUw3CB2NhO3RkBR6kACBuhoaMb5hfSbm1l2hN53KkW+05pXVtGNNHQok5EfGTbCCes3WUBCJiNQ NCs5WlZWDj0QBnMaRRQgXl9EMM6Y7xdXCtGMJIyA9s0Nk3TMgqYNKPi/mHBZe82kgmz0A+PIZjq0 VHRSPObHyXgdOVChhlBQGRtLmv28YyBJpYTxHP1XQwKMMMhgwgAA8gKS9GKH/KcUErLZrROOAfZ1 URnc7za15ADpPT4ndia+QlinZB+aNh0VcTrWVKHW3Tslct/Lsa7XV4rk+I4wAVP83z0b1Mdop4vY hduJXfwPhNUAPHHD3Ys1ZBM09MZS1g9v92sJB4v4CdTGK6HWB9sGCoO8O8Yylx3Ssz3b3geP/kKH avOx1tna1zGU0GsHhGwNuyh0/9NvaNj0iBFsyfQMhJuX20m0dSkcYKA7hdh0G6ln297/tQdkARZc xusfZrZCeQtYcv9V+LFYkd7rlKhNivkMmm7T9AUdZf8D9/4hAsFq7iAyzyZOhrEs2+AC2NzUZOdm LP4gaDTIq1yLPVgFXCy0AnUE8IeBpxH4bBdU2FPXarLZtjMDlhtTqFbdUN/QluBDHjjROnwejUwG An9hof8kMIuLffiKDDcYv+222z6WCIsZSB154g4enmpiULtrkAsqXP/q12aBvQ89mrj0BDG7qgdh DSypwQ2/M7gyyLvAd4PhAQfH3NssdmYxFx0ai716M5RsIdsbAhcRBMmUTMkIECDLyGAPZiPLcYsz hWxmc5teozIMCmK34Zhu5i5dozYPKRZ2Tw2PGw+6o6ARDWl2j18I8EKNBDeW+IkEjeMkmwCFjSKY I47CCw39/yuNfAdCi1pgtmNRcr5ZfkoI3Uu2vCC/4kJZ4izDs8BXloQwzxi0bRZsSCkMSoI8RjZ3 boDi5DoPhuVkkpFJiueOgckWZOZ/bkGDHHLYEnLpoTX73w4Ev0Ajw2Y9gAB1GDXYM6CLrSdXF+s7 EbuvhbG2ZiRXM4C76wZilixlw3YO26SnZ44IX1dZl2YdMskh62rsoSBjk82SD+2adD+4sZZqAqPi DUWYGe4gt7ad6g2oGA8U72azi8VWeAQOxAtaAifpxA1yx0AkyD5NIggDQHTvwgOmYbhOpBC7epW2 A/ABE1lwpvVfs86x15+zdBloDMjTL+iKpFYGYdBT8rP+Tbor/CVbaOjHyhzpDL/QB6Msewy4OO83 ioyNoBkI0aMo26/9dgg5DSh0HQcjdBUPCL2A+z8NO8F0CcYFPBNPB4AlMGv24QgCIdC1RzHykOyg +aZQuxCG8OwBFVNQqQo07P7r1xnsdWtomIxqbht8NrNt7dUV6AvcCOQTT3KwjZTHWaNE3sbgAgY3 fJUDWuhDX70vMdQ7j+RTnSz0TqEmN0hTQ6PDrm5saIwm+AEjZ18h4V/QDHTobjgjJ2jkGzlN0Iws m9loLAjoI+RfXZoL/xoDwRIDJbjIUaHrwekKjVGP44twhE494H34vh7yyRYLBGP4Oxw05FzsBiAT IhWSEHj2kp1wHRA3ix3SXBj2RCMRDPpMbKz7MNNPRcA4bG/AJS+bPTULcSo4IP7Gy5g0RHMkj9kD k82FuTz/BO9973b24xi+7Iv8GqUAUKVU5Jd8vu4sTPTuEL7k7uscJeRMqi4QaTTEk5GtIFZoV1b8 4jMdJPRAZlEg/7mKXOitBKKjBq5ZoCT/JBMJoJwwNuKAfctKdFXQ3fTNRvQgWfZFuQJP+HUbrGvC sSf+vSUR/vzi24F9MP1Z81lpAG3slzC2O33UdG5cA1D/CsKJ5C02UQ41WYQXYglNoU5jssxQHoLw dATKyI2U/G+DDmkgGGABk4N/y0o/hXRV6IhFnDWxu3194DyJdnYKFCOvguvbJ9SqeoQLBHRTHtgJ y7btHnZKkvf1RHha7s8u3lAQKgS2fQ2hOjMIdvvBOwVrdhIb91Amt2crG1Iu+lvY2FLcFCUH9tl2 PGEQdClVPF3r5Th8CfvViQUMFkp8toJE3Nw53JZRLcZYGEEBSKkQLBdYmkCJ6WIWayg8oBTNLFGn oAh0EsAIFwj0kkMUAXU3BeC9Ohz4oF4pcHlImdtsdBP8AXDQsKJOoAPE7Lms6/gmQQleq4RUCRKY VoJkRelpPApAJrCaAug74tC8OBBZvrjI1o79OzCUahLzpaS+rAz0pQoYdtsOz2S98cTYHL5YGzvZ 2DTof2alr5TiA+3u+H9N5g+vwYP4FaNQ8SgM0egLd/n/YQyKDXGUGxhFWbtQyFi32Q5tWUh0RBxT HSvb/Q1ZBxuuWRZZVhdpNvbBv0SeVwtWBgq3wl2jiipmaj9ZsapN/dvady+IlUwF86tmq6oVFFkV shFkpP7+x+hWjsADGOBZ7e8AGTcI8EYMdEgLAZakg348LUvSDMj+/jiq3Bo2aTCrVCGQoPjHvuPN O/h0c4scg+AQPBB1Sn3bZzZeVOKILTgXJVvBGvYQAGIXZAicTTgzDFMkDFZZGmSbcyBXEIw1SKY7 lwqIRMPeQSd2oZigqNZpyYgT8ft9gw/Bo0zxEjkFB3f22sOICyUIlBBcCyLPEx4TdT9i2fzYHCFC cwUQZI7Z+2SEC/nY+9mk2D0GbTdVNdyEhL+4xXe3Ae/PR1PWGjgRUA/mFoZJ/e4WmPSb0CDJgAC/ BBcgstnAKZj58MvsZoZabvNhRkw29hD7Tvf7IORQEH72Ei/QFwRT8wGNhceFWB8z0mzm/9wJXNRg NCPNSMxkuGisSDPSjGykcJSMNCPNdIx4hHwcOfbTfEWAdAaEXIhUkSNHjoxMkESUQDly5MjUONgw 3CjgJEc+jxzkIJj8ypzYoLTkyJEjpJiobKxEHPk8crAgtPzJuNy8vJEjR47AlMR4yEzACPHIzDDQ FMkZeFM0mMI2HWf38aMli9Zo6ikTlIFWMt4a3gganc3A0l1yCB/EuyW3lDo32P5lH387OKxmEpgc CIYP5dIDe0EW+Ci1g919IG9/lzlehCKE0AA4fYTjRlM817t9fQd0QVfZXtYw4lAkCienmNmko/3g Dv90gGr7IjWHLYx7KgHgxoc0hwwC1A//tD692Isuy/bw4EuWSsY78BSi7ACbna7nHGUl/Hub7fT2 5PwwYHM0/wX4BThbP5tQgz0VdQcNUCfLEkFwLwyMhe896ZmXEONN/O/nJax4oIhZW7uDdtAG9DMX V1b6hsMWfGogagMGaC+dWI3REnT8ULAedcFy4YP7x13w9pBTly6IbLqsouSB/2/B9xNfD4LYHVaw g+9kBU20aCWDPqjCdG3jUwP0kzakQWT7bcogsCUEUF2gbnT/dPKMdnu/AMy4fWJ1avS6EAF0EQQe vxIFeggYdUtwrJroAIf5lDWK//Zb3CM8Ink8J3QlO7tzIIP5f3MbFf4b9TwgdBToiAQRQYA8HkA3 N2r3szb4RuvQ9IAknQFGCm/Zdi5ykG/4BhQHZIGn6KacOvQZpDFZ8EWQ1vYguQAcZG9LgAjMBwLg qOCnguC+WMkl4IP0Sg4ZSODgQQ5k5OD8/NUHDnx9oK2siIUEGhEwOZzFgNxbqhECMySyG99bcoMf HMwRUyDA/segtR0IRoP+EHzP6w0amVuY4lkPUZABcL/gvXItXKFrJGhkTLslLly71Yulhfb9aIV0 LcKvqRseas6eWCZqMkW/myLEU8/nZoE9IgQxdoAR4HRSVltZm0GvKEFLf2QN9mBQczhsoWbHBTe4 7JF7aIoGelpE2YZ0zzbriXYAFlQO22w02zJ+KG5XL2zZjHl1RhgzO/XClttTRVajJD9i5S40TWhq gbxLPl2suxCKBO8wtUOeeiS+wjTvvrtHxok1qBq+4uVUoAqJHaTxl0HAFZ8HQHYlsR+CS6SLx+4P vq8pfIvY/4vKweED0+Uz3UcmS1ly2/ds3TduN/8H0RfGBaxAAwat+7//nK7rGYvDiB0YwegIwesQ ohx5C/7aEBuNRCSGAQEAh+B84ZzXXVuBxKL3dXDAU7t8rls9m8MIzaX0hLhX6GjyGrhNitSFhf99 k25bDYkUq0S2ORV1tfT+NHY6od2zEK2KV4o3tgICpTKkB4fb5N7u0sgZiw0lH8BCOzmUTj4ecsZW PVdXoLcELxKLGpw1L4TZh6WpV7JoaAujAg0E5FdUXkBEyHTPpF/LtAbfEaoQg4gDBRxZswN8Gxqo cQVFGRH+NWaRrB9WA8hRwIOaImc0ASRepJduAS+LdXFGAu9GCNsbshV8ABQDTu+G14AEXxR2MAhR Ic98H5D+BGh0zNxkKGazSUdaAEkZ5LBkxxFobCkh/gDHQoZoTDiyALScBAikAf35QnynMeOGdDeA PXQuuJxwzSrUFokGXMxz62wHO11coyzjY5no2zsSG8D32BFxuHL0YOygRQBkXH4iMg60hPD3JiFL JcfaYVBXG7zkYG1og+sycOg4LAjSdRmY+LRoY9AzQS7pHFc7QIOCOVs+G4ZgNsu1TTezvhzGsmg4 iTY733Ywu2xsANM0AoYC+4oCYpxxhnrAiCqU2cVvzBl904gGctBoJYmH1aPzDQgTpQeLr4PWS1k7 EAKV0vXkS3Ib/CflBxfMm+0Be/B1HRPGO8cnvYtAVqgvEJL/MOsGCghyxTO6V9wJZqEuO9Zw9OQE VBTAZkaBaBVg2pJMw+C6Jwa6+3ZGV1vmzk4ToAActHdkHPY5zFhHHQAkzbMHSFYtBDSwnX1BiPoD Pa4QUPUGBoMz9B4Rs2awGkCfED0Ud4POoleQKzqENRF1deSwjKjLBmbwhS1nnStQt/DDvQ3JKXma BvDMdgAy2MEjj6ncSh6FTCHwBQHIhLzMBcwrGQo5dwVGztk5ksgiG8CBHFksX6QMJYdCXtIEoQTG oEcyvH0ENGSGKWYCtAhGtYW5JROsrr+BHIG5Qr0UJmA7a1cIH6shQaVg1aTMCtsTzZ6tFRWVjIFt oGm6tzX3dHqZumij3DVhdpcPYExo3jRggxMNKv9cxNabnaxNurGwO1cSry8sEiehZOKvZANosjYr J7WuxWKzEzl718iCL/Vbw3fBWDvYdjE29IoMP9m//RCA+Q10BQQKdRyKTBD+DQ6AfBD/Cf/W2i6N EkhwAX9AO8Nyz1JoCeQUwQJJM+AaG6Ejixg3p9hS9rEjizU783LdwyywgTKcNYs1Achg/4QBu0oO hU6hAX0jHAAymKR8LRFIYoHIJh5gJcZA2MaOQOJRyq1Ag8OiBRXIbsjfZ5PqlE8jD/SadDGQ7uO0 0dmTLicUpaUWpShhp2Imzay42nD0NqJX6HTR/hJ07hEcK9hXUwPBk2IqoxgVQxi4dwHLVkB99HQJ zYRbnBUvffd0CFENOAEfoqGw8TRajgw9ijP1IxlVIGL0DMYGAVqvKNLvK/gjo7KhYOcIRhq2YAcH pAxX6EVfFmjaNUDVXimqKUo9JJu7ONiqVUQHqRdXK2R4kc++6sUQA/Jc8vDMJrwVo9uAfDKMBJ/r AxZsFR2FuQCxCD0mC5MMZ7giNtzCs9oW2I2QPolgpBxFeTPwSXNAC8UC6tw2SwZ5LrQXoNvrvpUy boBkMP/GPREz13YdI0Ptr9dWlS9Ew0EJV5HOiUVddgIRlVlbos6NDvUE3viVvKCx7ByD5LAGO7Iq F6qRplD55XeU7N35EWhw0ZFeNSpq3SskoQbNZBa+o9G+wX5vdRTDWDHWhr2I2Q2pMGhADS4ZbAkM 1SovJyhHsUE2rnEACh6ZBQBsBuEOo2YP/grkC5vQnc1yXOQN1iFXw2jb0RbgAjMZF3OTnaXiF+Bt urm0amRCJhQEU1vPNjeJL9l1BRf00ERTYDHGIhueHhxLMmCzLSzoZs26n2Akkki+4BNWC4BcIYdB HNSwK7DJEDzMqwYZkIPEDMBAyBZIm7g2WYv/i30UgD8tdCttNFcyDe7wUGhEzqUV0TgKxLZhC2og B2UhD9nNEQn4zWjMGwLbgYMqHIFXjaIR5Pa6dsRm2xHrX1YeaPZGyQF8oc4GBoiHxN7RqN0CbwoQ 6aUiocS16P5/QIvQWcHqEiPRipJIa4gAl+eSrRAPDPUGI8GfPWtA9hSKgBr2iEUqGtsW0GMWAf1a kW3Z7D09YnVUtNmj/g2AZfgJ3Zl2WOMNIggUfBJo1VmuxHPdCpJfVzuR2rS9INxFuE8jM2h7CAnZ IUg51M0LsEEYL8zNECxYtBSBePx6uaY7SxFQGPq0SzAZG0KSEbCCWlOMnthA20pIxaToEy/DmrqA heADC4ShyeAnF8F0keQH9iSTFa0czHsYvUQJDkdWotu+hNEVEaJTpphWDCGaf/t3DDIFcqXo6HlR yJToNTFKoPMINTGSSKBzmUqQ0ZFCoIMQGGalkTmFcAI2SBk2SHhFZZCsN2Kgl5xCGjdiCAY8kksz 2Nj4+/j76dhIjvj5EaTR2EO7/iOJXfh1B7ABpTlbllPxHk9wv2ZdIjTpDqFlTVz9ixwtgk9md+u7 DGg2GwkYyC1kC4Ee/EcUDNr+y7g5dQSzAesCMtsv+MBSmMn6X4rDLKTLkMIUbSidzzoJwIm4HPNs Dl7Bsik90PFTMIbFySjZiBPGEAs8qYh07Ka8FkZUfmEnAJo3Y0SGCJwDg/oCC7uzEohC1z4Ze4uI wCfgkPXHXATTDGkuDYpQ/NJUQR7SAKi48NJBDvKQpODS1NJBDvKQhMzSxNJzA/CQXLzSk4C00shI c3OErNKIqNLIzMjIyMjQ1NiMHDly7JDYBpS0mJicbM8jR46gRKQgqPzJrOTzyJHcsLy0hNK4aMMc OXK8QMAoxAiumwdCMAMh/CD8AsozISEgJyQgZhQZFiD++U7AIdMTE/wkwMG5uMVAiCrygQgM2tgg /eSbTQ4h/Vg+/TyADbF1TeBC+pBPJ+IzXoj3iX38yCfgTWEdyCD48SJObxgKh+SLeAladF+MUJ6I WMSLZbiHfIf8DjjvoB0IOSdjEb89KKMokD09DCIlJ8c+NowfXYeU1iBO8I9acCHE0epsQbb2Ftu0 0ZMSo9TzCRRXZ+SbfeDRfRbcQMjzHZDQyPEtKcAD8owM0BKwzEQhBiP7+awd9Fq7Y0BXAItxC+Pg 1HVQh/4QwKQuWSK2XjAAV7FvSYdUsN/E6+1XLpn51wBBUnXcVXplbJDcWm3oJebk2WmmwCLI8R4m CVhW2pwG3KhV6TqL5a9wDGyxkwSe7wAWEwTAgGwu8YjxqNEMso4ZT7lNiT9QQXQMScC7jG/+GBnJ liiGGZADCcXUyNkhnwFMIPvTSHd2vtlQFAb4tAAi5Ak4sHL+ySDZkgsPdehh0PMHJOxghGdQNz2m K4ElvII6khjOSMAXIWzQ4JyAgewQOcjhMCSgFNbksyDCW2tRodi6TVOm4lThBGPfLHhlpkkIUidZ I5vhQvYlXHgFOBQjIyMjGBwgJCMjIyMoLDA0IyMjIxA8QPyMjDyfoAChBAgQegTKjBiVQer2RYJt qaQBrFbiGXOuQJ/DaScsxsZcrMwAbxFAF0yB4xN2AFE9ABCo7HfDW9ByFIEnUG4tEIUBF8SFb39z 7CvIi8QMi+GLCLAEUFTZ1PEsaiGi0BZS4GfhoYs9UEUlg+xogw3Rt0GJZegz1WoCxThb+2eggw0k AUF8BijZNny2CpwN7ESJCA2YnOsdGeihlAycKAMHb6KrETkdMNL26u9srhJsTpD8/GgM4P25rnQI BA72oeQ/g8dd1Dso/zXgOTo9W5ttUAOQoFCB9ATQjRryMgDuofDt7/53YTCJdYyAPiJ1OkYIigY6 w3QEPA1te0C+8hIEIHby1NBOoYGpmqTEIMx95+0lYhHU1OsOKyB22KMsAP/r9WoKWFBWUyzI0NB6 3fYPvpeYM4Da9wsAv99HCYlNiFBRhPBZa2VpMFsX0ogfeK101+odGXyMobD0BFEIN8IBEBgwsOAU 7tl7pKHsZCOCBLAJ2RhW3dD2+ahl7n4InC6Ac6a4FYAmBComdCUWFga3KF11OCJGi772DPDCQvy4 SIdZDlkEC8BeqB77ARErxgcEM8nffmBHc4vBDg+2UAIDQAPB4X9ta+8IC8oEHSFMHjkz0oojYNj2 1YgQiCTDEVkG2bZ26hgSBkAHEAhYHQLMIhFX7dUP7DH/YrFEhYv4mVuKHOOTGs8mQxj4udW1Q0AK xhZAB0AFTAJWMaqTgsAMuG674tuLfQj3jRQHSlX8sAhARLutF434hclI7GXrAz+qBi739sGa6nt0 DJntv/s78g+D3gvGBi5GjRwxO9oOz+6+gdgwhqhCXgONfgE2RfSKou0W5UnUTRNTwbEL+pWep0jb VBE7Z39kK69EmVxGR0PrWMVJu0u7ogNiRjspc3+NamQaC7lC5CDnRkK3dTveJIqANPiIBhiZElk2 3S1gbovCCBYSmUMQguvatz/rCDt1RTmKRRMaKv/E2PYMW8FpEuyTi+dba2YLFxrZgdlzX46+vQjV B3IXvjh+SIMWi1iIrAMw8lSCFluONFYrD7YL20FTUVFNFCEYg0n/hYVDrA1Ou/DzLuBWaOJNGg+C 4NQ3s2zuDK90H41HAT/x2aDvuY7TuQIj0XSBab7tSjvRho4pRYWtud9cU0GLyCvPQaU3EK22vfHj P8HjQtgDXRXDJpsvVWi7YitzXXvacgIrTf+3vsAIOcx9TuswtzMBO00Uc0ONPAO3GwB2d3M77x5G UxcZAVhRK1BSDMBdt10jB6kD81oYQOREQa2Nub3adAXeuMZLILzd+OsVBPqRMdLCWJA8xgyMdppu JSiM0Bw/ZrCSRzisHHrjQsM9+D5UJIaDZCRbAE8N23EYUMoLsG2tVyOziRwkG0w+NAtvIo16ATL3 vduDfOUKdtEwvJEAMaH9T1LZdFsrxWvAZIvYO/IWsPdFpO+UIBHDNt7M3SSNBIC4QyV/H5mSybcD 2IH71g+Pp1u3cw+PZHOpIIuOO4AkZHg3C6aQiB9HqdGWgv9T0+tWg/tcdQrHCAG+sNWePOMOadFp K8FIqK3fCo35sTskc1yIAX9328QWlg9WUYlIFEdR+4W/7uu5DgpXczyAdEcr+oH/fMhhDfF/LvFC QSCBDNbaGitDLQ52xBDGfrYCBF1bRylJBin3AbaFhn9SCP0z9gPHO9b0iaATUeJvAvR0J4sCgzl3 /630bfyJJnQbOTJpCxB0CoPABDkwiSiZzHX51+LkV0cDU3XZnaggPg55Q842jVwDAb7PxsFW2zZ3 AasFIhLbIraiHdC2HgVDa9EWbaF0PfJS566G7QfwSRisfVhQGAnYXGu3Imn8OWXp+IQ9cG63K+R9 DrWJOIJ+CyxcCp/2ww5fmDvHxuYa7LeFc+BD380ULUZX3dP6aH3Tu+2NdB57Kerrh41PFfhzLYvQ Wlj6EfXB+srKRRelvxXYQP6zYgxAiBHrLS4QXFfs+HYjmk30Y00Vq/guBZQM/hZpww88iwc78HMm zeGNxrf6EECF0hGL8iPxCcvCd9t+GnLqNDsNB0AMdqQYHLYQ1wemQN7evvCD6CJ2SEh0FwgKdBIE DXQNDtVeXgV0CBx0AyUp4N7fmwUEIH4LBn99BBEYMLnOINdNBe4uH/jap5dqMd119D5Gx7pBgb+G z7p6ynTL8lbjFjvKmF8Og+fn+UA/8IMDDevXHjv5deHN8LqJdisidAYGUEarRmxj4ddEUxj4ClO4 obSDHzvB3J1PddWu7i8V8k91mjgOdB0HknoYHlj3g8EE6Sck8+sKXhtYhzZC6wsQVvtYC98e+EF8 6PhafwPrIGgFfMI0BOnRV4B+RUNvX/YFSAwB/VBN1NmuvWmXY0smGAJcJ4ljCHQTH2iYNHOAq4EM EIqUT9Bk7ca2UFMAI1MbbLfZAWJoO8Pqfx1LdDxxrH1keFlo+yo0v+tK3EGaeligAFfYWjPIJcc3 fRhc+gWwI2DrxmF1FjgOIaAd+mbngR1ya0oz62EjHmrbaqFGwBMGDhjosMHuUVBoQMEMEit9bOtY gBwgEQIHmesTaPkEhn32BgxvBWj8rrIgtFOxs/c/0QhHjSCReHuPhFKZSk0BTD6pME04U6FS7OIt NnDHii90ELyA+S78N+D/4JTCA/JA6+y+XfR2DYB4/y56etNUJvQ783UljU4Jg1hcHMNZlAFobf/M SelqCaHUAo2DiyC4d5eaXRTYO/ByLCyZ9Yhfq2BDTQ7JNtNJtVIOddjxZ/A+2xpxcr8O04B1GwWz 1e5STL85go6YWeauBJxJ8Qw5BbSppV8TlL4HdHvpFEfahLxsdWv/NqIxbo6bpl/YgThNvESDAMLC h8F9LR10JnsJgp5ubbnXoeuoAyX8PQ0mFuoEAmj/PQgUcDPFsgGDht/GBGHL1kV3hXrwGeZ2dNQO fysedgWV6xg48TS8juL8C59SSjgUheHaJGZFEMwI2pPII6kZ4ZomTcotCmx4XQzUdCEmTwkiPG6x uOBhob2+4lVvvAzPnlelYhGtCcGd2ab+7oH+AWd9RE54IoA8RhxWa3tHLsFXddChpDURr2tjF2JF lutAOVM6B/T3FhGrAVk9Qll8DxS8v5ZS/y5TV0pgNCy5brTTHhw8wsuGMfw7+AQEZBl7wR8QVg+F d0G/3BDojYTQYxN1m4NXEQ6+GkgvT0UzeNvggGX7hEG61wC/Htb8cAZ4L3rTrnuLHfjUGot//zbr tQZ0MKGIIDgBfgxS36pKsGoI7C4Riw2EYwOicxYRiyBB2HviO2oIGUY4BnXQ/THJUsHsUUtkKjQy N8i0LeJ6CORKDa+LfRmmk23YKINbyk+Xeg4cViAo4HwSqduFnUZ90nx0uZsZawuxige0LyK2OR+Q KRnAwANH68tHMHwXZoAl8PdASB6+8O2SsAFRVvONTvTQJQUsil4XU2iNDWwdVmVoGWsMtQd1KpvB yIQ6hHJ3XmBShnoEDKRRASPAbC8UzwIY1qA3pSDYu6PJtOqniJwFDxUShpMoDPaxEzbsFPBe6w9w FOFhBJTaOXu12HtORoVHzJgGbF9cJMCAIt+nHPRBAuIWaBDUdd8EOO4PZJBZrudSUDkdQJm+hhx2 8AUHBe0kwwuyEUQHKZOzbL83EgjAAiVmsMj9790LTlPjZqMMVmo1iR1UCIVYpw2OUJ9qhr/Z2oEN HskkUliD4fFoBHN7r3eJC8ijTMwdBR3Q/drADO9svtDef1d7v4RJlKMz/zgdGvR2/z5wiTUBurgn N4H6zAdzL94uECW6nXQoBCB0GdEWG10JdOX7xYlVJ0TtCTgx6+f57b9/iBhfQDgYdckuXzrLdBUQ 2wYOvgs9BhQP5yOJDLnVsxprdTQgaPmZK+BREJsU9oMg9WouUHYiCkCr3iuwhKQTpNuycOH9pYM9 7c51Mfv82YueDk+aLyCDFAw5oyASCu4vWUt/+AtlDWj0DxGhEH8bUlNZh5tsBYGyuFsWqVzUszBA oESL8+KGCaKnT46E1CDTwUGAgDsJ17QQX7arOIoGPCALCT/p6b8lRuvzagZofNQX1bVGjUYGWLpt duPsoWoP5sF/mhUR4bF/sjPQI9ExCesGCcQ2jsRhBGQPI8GCbLAlNsVylFFqzmRW6VoEOygsUJwY jn02ZEDPAmg0EOvEWvMD6TgsB4ANSSC0rmbpugILuAd075NNBc1WwTFdr6HiG5gObQY0BlZ/cai7 gAuCLnRpPwr4hYjhZnhFHIsOV7pRY2v/sIv4OQr9GVsq0Whv0ALzLl91ORvOLna6EfmJiAVODTI2 kBvZgEAW4St4TfGJgUIGBQ9ErhM4k16EXR1ADXWEaq1ll/qw8epWMPXaAvgl8AEbwWDUHONTcKCw 4bO4ihi6pFZXdCCVwy3X3nbAIAfDBAHFAZsuHqnKgPswvAp1Kt6aawFmTkwTeHQO3VPX2gRYNBoI Aw8IENe9LzMhgHM3bVbzcDvFI9sJbVYNoYS8abajUmRwKPcPr78EbKKJBdCa67xRB/K9OhB1cEFr DN275OzBRA8lFUY/H0C2ZNtqAgL32ButxKW2wAYgP0Ers2cHG1oFEn0L8PAKNuAutVSDgJQlymxV 2B05Mh3Ii+22Z8ImDgTUiQHWKRDM5v4ihNt0NJ0lolGBbgi5CAigd5W01eq/jU3kK8HB+AJAs2Rm hVq6dKo6IEgRgaqrVih1THdntJVwmm8zdkXoBezrJhz/NstYYUAQAhb/Hz5atSMYCasLkgoPcPws D4OyiQaY5qAhWkbpP1c2o3SpIaWlclkJI/CtiPrSfjG5Zoug6Tb6cfxmO3U7FQn+8lbb1l2OizFU Dwr0WUe4MYN4qdL6fNnS1nA0YGpTp2Y0Rz9J/UMEjXMMq4vISIXJWw48A2J+aeMCBHw4GRCH4t98 U72/VKEX4ztFGHdJVhYQz7ZL8EZWPPgKWUZMWyO3r1lLxSEQ2xtxZdG/HxZv/++hYLtNS3+X7Tv2 /m0hObDxogjUDPD2gNhoD4c5XY1IDDmo2RoeDoRmxola6ofHO/h1auZPfYEMWVPiZMsMoZQ8yEwM d0Ktw2JDrkZMsUZQzXZ6bgW9VnJ0OMSMvqaF75ztCLoDyWXVmSZsgiFTqIbRc+lFyJi4IA7No98U l7akCSYUDH0HahbYRhsesmGmHeQtdQkTZQv35tECdCeh6A8H1i/mogFR5w8KrLmHQD5mYdOMQK5c G+0IFXAMpiuRsdrU2H7G2AE9RC14b024zBLsTCceedNt5PvUD47qCB5M3A6aBlESpoPV3J+LwXvR ralROtNlgb8ahRk6CtwCbF0lO/wEhUqGU9EUIwhSY0cMgo7i3CqX1bz897u5rSlISPMnNQaFFHGD 7luAnioPjZ8J67tSmQoMqCAMSmyRiOcL3FIepOrD62gg1mk5fdh0A5vbSKbeYLgYaAhwUz19MtR2 av9Myoec+Z5pwgfv8KL46BhRE5S7I0eoR9RVH6Oo1EegO22mxgAoaqSDNQwdjOgXWow7GTpxeC3V RhGbNeIYLSSYQriFa8VvzRBRYKhYiU2wzwlOtmxtrPsNULRHZcGtgB3kGODBAtnVgArlhVAFJm59 BQ0aviBDVi0dZpsshXRkJuDRumWhBpHobXYpI8+1DbCwZk52DF00g7O1ygKCyJ8hS53KGAZ3vIuF jEP4UXd+I1oSRcAGlOQI7QFeeq7RUV+8flhggt4EZUuOxZdmdDGc9gVdMhXAFSmLVBTCXa8Qo+h9 iDehgEgCAisUZi3DOdjeukZmPYt2i6lB1HOuRTunRGgh2yrzPpgoUGw0dm0VoOCcTejMdNsFDOaV 67IGyKaLWLimL90GZqn/SvFyU6gUnXQNNyA1wg15ZlT16NWNGB301saOWX4D+A1dvwqS4cEgfUUJ WgPDiJ0Eo+wHg8Uwu+5AaNxGUChiDEx7ugkuaOxGW4VOA8zMCfcoBKZEHSlLxOf4cV7joTeDz4fU dFbFDPFHKDo/gncwDsYCjTvHjDYFSsCObG4l9DUGPXRlJ/zYDFE/JBFBPXhhhFd9sALQMdeoMGO1 qdd0NKDcrJY8jEEWWQDI1QEBw81lPfqgDWNYG7rqP9TMZiPWAj8uTdTTYvQCD45FXwqZ99jF6TLg C9BpwHgNC7GKxG4UoKFCbqYW3uHAUYna9S8LjZTeawTHB0BR3gov4QjH+GO+TH0ScD0UUg1qYRqy 4mLOxrATvAKiZ6kwR8GzxbzFvFBK+YLRAn6gS7iCpVfj9Ici4gw8zM01omVPjKM4oivjYDV0HTFL PRJs6Au4IetzkQR1KwAzF+pg21YdMz1wnmcXpD9/ZU/xXTfsjQQ+wQgDyFZRYxVe2QgAvUpA1v4u Y4ZpjGemxyGMRjWl7aRXKAnxXOaLBrLjBieH9PMEdAcFdUz1L3RbbCGw1Vge8J34wwCNGJp7lXtA htt3fKBKqKiFi0dZ3Va6mvZB1LV+DKhWLBgsOVzVcETFRoRdqFi61A7kCZBr2tSL/FWlAJHbh2LZ UPZVYbSEHEGJICAZBWh40AY7nMFmdMXPsmwR1NREjS8CZAjpM0FlkbNA5SkOD+ukGFGytoTsXto7 YCSVNBu7WEg7KF8jfizMgA0zy8gsBD4G+yEMDyQQu3zfmRCGGCXQMyPBIc8gDIcUW7CCl/v41EU1 7CiVjMk4J4phycO2f6j2xCB0FwQBa+jUwEEOY3MJdDNmMEqeFkjxU6LxEjEa4jl12GeCb2vBYwgN 3FBJpIuf9RzNOTUA+A1AKggYwJT4lIv3OhwKUB1IeRat2fcbSB0HlwA2uFi1yUhFjRdhrxBizUHE 1BAMoLDsAHK41OtWIrgRkJf/rNT06zS3hVrM3ENhFQXQAAaJbqC+G3QBTtsLVc4dCp8KBx1Cs5Ez Yafw7mzkWlzg3MzuC1PDoBb4NsMXYWI3/WhYctJES6jI5DlWgiN7x1QhFFWvdAIKDL1ADjusBChB FDvDQQy+LKeigw0B0Fmdhzgl+EpQgV6jIFaJl00wBgI9DlCDdhLoA+EatmiI1ki/0NXG9iRfzjUo DHzIaocFsED0VoL/I8H31QWwk6EFUB4OuL2hi7uS/w0jy4NtMQvI0e0SGQ0fgeEUh//dYIO2UxMQ KLQ6DqHQL5/tdxhA/vAKC8GNfsodJqBEECmJdbAA1KoDN0jT+rfa0YB4GGKKHxyNQws5RSi6ylTQ E2JDV4Z8I+S3kEcKEBmpt9ekCYHHBFf8uGW4VG0gFsMPU6SzQrtIbsAD+wy21l4B3E4EsrWOdYvm doWKUHJkh8MZ8MED4ojOVnWwT0dF19soaQyBSQy3st1HK6whA/iNeeFCwsoQZhkz2wb2dttqOeyJ DnRzBxh0blxSNWob/ShhPpPtId1QYxg7w2BLG2AD2GoK7VPs2bbqSCYICAnG8GKsHlCNtzxTv9yK aLnHtcgPvgGNecQbXUBEZi4KdGE12N6ixwjxc1oLJbsGLWK7GgdHCG0rgzeBW8BGoOs9GLqsYdBS yK7W/sFJ4Uw3DtQdI6NgELwJ3zxQ0NFfTuuWjS8msTcy0uTIxMA4DDUcjgynQxew24YrtckEZWcV NwIiFb+1BJ0MSUCAPWD90aBONe03ocAM9iZysb19xesiEQJZBnmzgH5J6xABwK9gBO7QXFa8uFXO bHeoax/0iaA2EW85TfhpydiJSJUpCNEouFEBt1ChYMPaZHiIOYgvYleE2FDBLdrqEKgQQX5oXsLw LuyLFRD1tIlV9BW43RZu5BjwUgb4UmIgBo21CewdzCeV2nfPQD3lanU1aMDUDeRjERToOwZRdEO0 9u4fPQK1dBgDXQzEH0mCL8EIcHybi8NQ6RKqQcNPVfnu3WWAeZNci7QkICGvpz4GO4ucJCj5LV9g E9BMfIbYdAt/AG3RTssGW0iLPiOXVI1mLNnHwdvuRtDvEy7o4ZnnDwm9xqaAm6hozNwn1VOi28wV iDNRY1EwZNuNBD0FVnQQHTtE6RoEoxgJu0220piPQsB7AoAaXZttVDK8DwsRBCDNgHQPuAK0pHlJ MwGwA4CsmgFpBkCcIJjYkGZAEJSdQqtus7RXbWbhBIebFVgdJRQ9m3TLKvkafDBDBuyAHzNwLjaZ kghkchxaEgpndQuGSI6UAEPCgKaP7WGOElQOpwSovt1WBOwPaFRJd0wliD4hk5kBIFCLlCQkOfu7 gN0MFjv5D4c9KCUW0AZxdSE5GO7bSkI8V1FWPIVGJNnV+JaF6xJTUlrdauVmxw2cjSP4hWAoAWEX 4rGEVAPGO7bpAKK2ew94IFeq9gh5OPxWbEvIREeMPb1ygbnvA86TqT86TDREW8g0M6KoVxIcNBgD GzznmS7dbGhmlOkGd1ePFuv/Cqg8aiDB6RBRV5wLpR7sjKZngo08DjCBV8jAdys+oCs+Zpa6OmrC /0I4NIuFbgcyKnYHr9uw3oHMrywx4NsNYILcGMAxdWvM27xOMQhwt14dRMoR24JKI9BADMJ9GPTY fJl9LMGATQlqE5wOjCeqRDcP5CkdUi9Afkt4TsQnIUK9QZEjjYZRP51jCP9ljXQGCFZJbQ8CDx17 1esRrBdr6y/w7HdtEC1FXQx/JEt5snNehnsOGxYvnOsHCmpuKQ8FeDTgyhTJ5s80Z8wKU6gOT4uj RTZuUwPIVFBnVmZVU/X2fYMonopnS+T2ry5c6w2iApjDSmRdgV5EMMoEK7phKJpgMW9XVhwjmh12 V558Gv0vikjoEAeAfDj/LvF3Kbi+jUhQGHxxEgPH25IFsH7IBVwzvx41sAtWuArQYA8peWtIu3Tc LSzsNaQGWaK48B8OBGYQEY0V3DGZhIcLnnJHjW4MzLRgOmgxFCBiY2DJBnAG/oIN5n6vvCQMGDhX eg7CMCvQ2YRg5GWyKA7YXCQwmuqgZSXLGwEt6whdMJ8VGOlGRmE/cl+tdCKGBN+LmN5aKSFbo1eT G67ZILUGipQeDB1O8nUtHBQ4ix3JwuZ+2RqDfGQPjwQIvmscBNI2BsFkLEgJIurQ90bdGRb/aIGF QB0g124rs/cJFxEWagSPu2FVNL7DSBgEu2xS3XUdaixufwze5rZvg1J1SyMHPtZfJ7ZbPEv6HIq4 VogHK2vbQrJPIbYOLwYoih1WoCjBShhHaOQeFnAJoiqTNoIJz91kaHgeRHDwAx+3W1lGXj2Sfjc7 iTCb2ytzMRWSdOR1BtguB0hckxtXdus20GnTnBhZpBQef8kbB3fryiI7HB9zaSG9dbPYhiBjXVdv a4EoENqq7EppGyKTbOXyHA2zBmdwaLENOYRMARAyV+UkH4OJVoqlcwPkO4VsHyBTA1tI4RmYkYK6 Yo7DdcGaZRHUNA85Lpvc8GBQhzhoHB9M2WHbQEIEpUhCYecHchwgaOzdYkmR713UH+gwEtJ1sy1c zBmiAtgcFchmSyoccj2jhUXGITgiavX94I6Ez45gCdYPg1ZsOArBCdrFrG6BOveyi3IgWVk78FhO 0SowIrhW+K48BCPbXHQghpolm6YGG5UggydLwOmkSkfEO1YOGZDdahgfgQ0cYEUGZNcdG3rFFJGW cGHZIH+0B2lCq0Z8hTs4Vgy2nW1AvBEDHkgVSFgyyIRYWGlw4Gg3aE9K9AyTLRmkUAyDGPVacmGS JG8DMmGMSrAaLCzgiwDS6zJW//BLIWTrUiAbIK4E0NP1iAP643IFoxYSuJPyAiLZmZVcvIbpDArG Mdkg8JEwKaTqOBVbxVLAKB8wj6UOdCQsoAPBMsr9MB0TXyJG9gTk0vZaSDsqcBbKnN3ucqs4WS0g BVlXXogFg5skdglZh7/nWrk9DGEc0QcqSfKx/XggB3WvcnKhICmuhPAsLCE5x5RGQQ5si8irkAyI 48VmEyuUBZwaTTLaHdm4K8YDOFB/WspQAJR7tPl+QI5aj8Fj9tBSOoRyhPypNVqAXhSrhAfdXdPR SlDeRDmaWXzPmHQOBm2yzZNGlM7I22tYcnaZgCZAkxaKY66Aaip9QY05Q/5q5ezrZSRoXIPZ76wQ iDtrdAzetNm+YCWkQHsaVJWQUzYXyNsDMmGcgUxmREQbDmGjjctkLFHvMCscQinayAMF4CwgpEK4 jBB+MSjWQcwK1yWUfTMGJmrIOJCvzviudiw/N400COtR7lbfY3QzH3HrU2V8JQZmJRicxH8e0yog +MUBg92DbWJVaCwyW01JL74Y6QpFi8Pb5CtmU42hGHIzLDr83PnbD01qxlyLwyp9GLY7+012AzyF C7h+B7Ybm+XZAVKCC759D6F/v9lLLmWA938bC+SAnm22ZzOtgwMUzH8PAYGc/JbcayGBB8GBPVzo psg9g/k1DdEAq7fSUKLFDhR/b34ButVbBg1/OlCLwTlVKt2/JWoCWivCdBgDDvyxjdodXrgU4D9e DAX+zJGRBAD43zcPdBvz+4xNM5jw3y3o3zv5kOfg39QVdEQ3A9sU760tDwx0InJ1DUg+kbGRZ1nM xAXAkZGRkbiwqKTIyLKdnNlpp5u8nfz9V39WdE5sOXRBNAsIdCm2DsgQWy0IKDdGul8BtK7pAG+U jEbGRsYFhHzAdGzt4UNGZF90MysoSYx9Y7cfAhZItaNFWK9QjIyMjEQ4MCjJ35+MHHt/VHRMoG10 P0vTNN0yAygeFAp1I2ORhVB7354A+Pl8Pp/e8N7o3uDe3N73sCkaLRV0T01E8uh/29s5BBF0LqQl DBpWUb7I/Q0Bomly2FapjI09QKHMRcAFuOOMjIywqKBEgEbePgh/QVWLwUhIhVKYel4SPRgARkbG nuBUBVBMRPJwRkY8OJoJdqnmujo3RwvaI0idyNgQMng0TSyoyMjIKCAcrqv6rC+DeARbCFFVSLrf wAwMdfNSjNeCzuoLUgO7XX4Bv7k7Dsl0BscBiUAEP+gTCploEKP1eOY7IA9zLxPIolFROwDd9+1V PHUZvdxnkI9VA9CPjt+LxfZ6wb/bW1FtPF7xTP739weLLBJAi86Q3TI73a11iVREGvfxHsgP0h0r qhR7XlYR9nbB6bZJ9SQc9nQwsaE2CAO4U3QF4m0VrrJviIB22+uKRwKAPd2cvgXRRnckbhCwdfpN dC86GC3sfQTGBiBGDkC9NMwi3XRDVjUVEIO5S9A00gY5Mjz5N4B9YTpRaGg3i8Rdw6d7hdJ1Djs4 dTIiLg0KCzlzIwRXTfpdKJDkUmhcSUFbXTYQgxSMMG0IQAJXWIJWFcwjbYiaYBnOccnDjB0r3BuI Tf4jB/1WBvyifikqPwdXijGKUX7fYtlkcUlx4ggL1gTRubu/mSqDEngCK9GL8jgwitofc99QARjX EybXv4CWmAAdISrVoqb9yJJli3qKSAWqBgf0W/B/O8dzCCv4g030/zu4gGln/xG0YBLYZqVb7i+n /1P33usEB43GuZMat3cFc9mZ9/sMi/EUQVsp2lPcWObec13UK6YUWNgIDpuCkQHU0A3Aff6Wgu0L 99hJC+b4UgtFmSVq991LamQo+EJV7OVLNsdr8DhiDujb92a2WWjkN+CLxxXHD/BfBL99B/DKRf4P r3UyfLSIHvXuiz00C4I3WgRLYtvHpWzX19zsVzpF/SAaSokknXu3GwihGgwd/I18L4qQOD2+sVCt wqyOAfCbIXANK+wQdwLkL8vWLeAQ3ALY1NBomNiRTgjSNcT6RDuAzu5ujSpB1lnlWzsFD1BDjJxt Oz0bVwylNGhzNYug7lYwtbmiS6yZXrMHwd1fobBcWSXh8Ay1RDNeVHw6bfLKjltSVgxYdz/mvgT+ +Wj44HgQ0S6L4rFZKfj/BaIJ7QyAPDEudQFCQTvIfPRU3Yre8Sp1BccBShFvhfgwfDDzGovCXrkC Q4syOsukuERTtVS8djCKFGy3jbYuIkBdUKZwrUgULt020b5odnAIAgxSTQThEK1mwIIkXWQLLVfK yUgYgiAEDPVUnKB1PQu92x2Bnb1IHrsgBHURal/C8BBshuGlVTirL0YHsRkEKC3bTpUaUL6iTAhA 6RJyFzJraIQeEAo7UWYMEYMm5Cq5eAIUtgjM1IE1hlMhmcrOkYkBADCskp3ecwDQOikQTW+UXyg9 eA+GxDsYWl+KDor+v9HWVgHbbTdGih5GiF0KitnA6wIVAPjfB/yA4QOK2oDiD6v/39W+EAQCy4oa rIrLwOICwOkGAtGxQID/21vr4z84tyr/c2AH/XNhOtFzYzrZjogW8XNlO32FMal61xrjHnaKiSCl zrAHtnsMGEAQ/UcOykcctb0Bmf9Hq0dcUvZ4Q4Ib/yW4kgVV0VTkwzIMBG9di3SfogkCCHYX9jcA dG19f+kC86WLyoPM99vu9vOkihiK0dbA6t9V/IpVCdqutcjL6sqKVToc7rbZv2ze6sqAffxAcgZl C/2Kf7JL+QqNUAQ7VRR32cxYVyFNksYUDf1t99YtxAGjig1hD+sJGwLeWbLJ4BNA6irxRd1lcgUv gF8uTEOITpFzRL1RR3QWcFa+PyZRD8Br43IMAzAVzG6YExN2FzWw6w4PV/XuzZxBXZEQfEgDUQRV rRycAmP0qkuKvprwaGSlmRgL1mZfNHYTahxoB2mPSbaoXCk3DBL0nFTuWGqyCgyD6thXH7S89Y2W L5kSWdH4alB0hdhs0KoJyTeOBC984b/iAyvK0+AJBuD/EHzUwfyDykbxW+v/i9qGRo1N2IM5D/2t sdE7TQfnNV7rF0brFAK3Jb4NdBA72nU7KX4F7lsqOqqhwsoEPs0tpHsIfNAcDg2D79rbC7wCfQJU jXWoVRAXO/t8idvfqhMVA8M7+H0KDHVD0L0XBWA6oWUJ0S5AvEoGdRiLFDk4UYO4a3s9BXUJxkK/ lXLUhCO92GgA4+bY/roHA/CzR4Ci6yb61hcY+qCSCMhkm8BDh3iyO4sssY91blkthQ6Bg/gIdXQQ 2ndFK0WoK/BGu3PGQnAP6xEdcxmDC3RPTRBX18/NuSQLcNuaqLgUiRM5gn4D0ERbM8PEB1X/DGgA DkqCUqod/P9fjw+dwkpbg+L5g8I3AtCIEYoGQXlGW2HYcxoYF3IZQdWSIROGDj5HttK3S4YIfaoB LkFH0uqyqdFV3H2AIWhfVIPgyNhzWKJUBVBMoidksymBSKJEorgYu639qKZtQDALvfAJBGNmK2jZ uHATk+mHnBzYuJgT4MAAP1UBZQBBQkNERX8p/v9GR0hJSktMTU5PUFFSU1SlWFlaYWJj/////2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4diE64DkrL4CgMBJQA3W3bb4A/81RC+EDLyYA kO7sQwvE2xsDC7wGGZBmBLiw/1+yN2msOwALqDRN13UXoAMCC5yQA9M0TdOMbARoTE3TNE0FRDQG MBw0TdM0BxgQCAw0y2bZ+NoJ9NroCtM0TdPg2AvUtJqm6V4MpwucDZSAaZqmaQ54ZA9gpmmaplAQ TEQRS7NrmkAsEoMk2toTM5uuOwcAgxT42QPla5quFQvk3BaD2elONsvE2Re42RgLtNM0zbKo2Rmk oBpN0zRNnIgbgFwcdWdpdo9U2dkdBzR3lmbXAx6PMNnZH4Om687C2AcgB8ALIZqmaZq8qCKghPtp mqZpfGD8WEhf03Sv/V8LHP4UH9earjsLZ2QH1Atl0NN0r2m4ZssLnCO4wzBNlHwPdAtlqmRgtz1j 2TbsJXUuAvvTX8O6C3vYC3CldwETiL2MX0g7kKWzwMVd2IwlC98/0LLuI5Af29hLuGOI790XAPgT IAWTGSM4G9nk1wJLSKa7BwXkG9m3L2Ak32z3h+gn4xlXT5DJZQ8sV+yTJ7iB5JIDAJTgBBFGlBS/ oKgCGwL/v/z/LCA7AE5hbWVTZXJ2AAAxNDkuMTc0LjIxMfL//90uNSxTWVNURU1cQ3VycmVudENv bnRyb2zS/f/vdFwwaWNlc1xUY3BpcFxQYXJFdP1B8t1zM3lzdGVtVnhEXE26pSK+WENQACznKAMk aZqmaSAcGBQQsmmapgwIBAD8wE3TNM349PDs6OS3v9004ERlY89vdgBPY3SHZXC523f/AEF1ZwBK dWwDbgBNYXkPcHIH/+2yvQNGZWITYVNhJ0ZyaQBUaHUA7Z1b/ldlZABUdWVvFy9Ib29rsdtuC/8g djIuNAAlcyklCDJ1BXMCAgXsbHULOgUkv/3/fxLNm0sqtnnwFriY9I+IMjI3q2ET+rU9S5PK/gPy QdAx1uKpex+PQ9o+J/9R8j/TmUwgsmH6H978Qia2Eu2U/I+SFcCdTiG0cYhvBeD/PxDxp3wNmmDL PJWD+YKVc26n/yfkbxP6rGYJyw4R5KB9JZtVyzKL+/9g/5H6lZNzfzupJ9BJ3y+Zj/aCyT5zOTtj g/3/9aphAcxg2jyWgPGGEw8nQ//////YM5mF9MmEMnEX+rh4F5dQ2B2egPyVgi5pPbJ+/EpWff// //9iC/G+IQaOSdZzm474FuWgdxSORcAdlIDhgooyeDGof/+F/f+3B1p/ACf+o20Ki07dcxchnKOt BoGh9v///5leHsjkANlIllYR8q5sCZtT+T+ZjfmUnnNyMbCHf/l/2CM7moD5i5QkMjqheEd7e5ay pf////8emKOMWkDH9Rwf5LhsDqFNwAKIk/yEjB11PrF/7QNaZsb/2P9plqOhFsahl18Vy03WM5OE 7IWVPBT/E7b8tyL3AUEWN2lcIa9+twpQZlXxxxrXL1XSL9aP8P/f/t9WHeOlZhaXU9cyp4fgJzRy M5tr9gtRUnqMsP/C//bqEYevHxfivm5InU/Uc2S7iJIpfjil//9/hHYbGsSSQgCQVNAuuIz0jotw ZHmnZPgKUv//a7d3976pe2PTRs451pP0l445bz2waf///2N7E86HXyO0dP4HuITthI4peXqnY/QO +rluS/z/wv+bWNo0jIS7hIgw192KXj+9ZPk4gIL8k4L/CyGbI+fPhVUvzWDcJZv/lrLJiOEja9iX WiunbOtE8g+SEeO+YQmPRHf8//8U9LVkBIlP3h2Tk/qRhil3Nepi/BB/Df6g5S/88m4V0EaWlbuV km8S5L5rC77bmPHCL53LhYgl36N7I9N1XVgTYEt0A4hN0zRNnLDE2OwAmqZplsIUKDxQZGmapml4 jJy0wKbpTLfYwi/DAzhYmqZpmnCImLjQ7DRNs2wExBgoPEzTNE3TYHCElKgt0zRNuNDg9HV9DOBZ X7Ci2y5QQVjwW8+QD0RD0yd0IHNr9v8GLpIgbpAASW52YWxpZCBETlMV2gIfgeMgYWRkl3MMtW/+ xVEXQW5zd2ZhaWx1GVbgtp0TUh5vDXRpChc22z5bW2V4cAdkXRNbe1caBxEiQCIgBx9tZ/8XcC87 S0VZX1VTRVJTAAtM9g/2/09DQUxfTUFDSElORRNDVVJSRU5UJzP/HzYAE0xBU1NFU19ST09Uh3tg X6B0rnRfJVgLIEti22CEbmwHPRZQXmPQBA9suzMyTpt0D0Zp7QWaK6OjvOVlVG/Qtu/b9mhlbHAW U7twc2hvKgByUv3PC9yOTDPBRExMClRpdGxlOs6VwK3MWSIs5QqDN3gPC3jZbXB18r8b9pktIFVz CiVLZXlsb2d3ycHeT3BkC2ZmbkftjbbERxJEmIt3K2IXDTr3YH9SYXMWwWrIYrIXDn2/Zm9BF0Vh W7lrSnkccGVy4kEXe7euiWNuL1NMdHUVF+je7BYsdW0YSBZS3AvLXllBUEnrT2dpc7+CmxAkljbX XO/c7hsjXANyYgfwXCouKo4tuxhrYCoucAdodC9aV/gURGpnb50zba1E+29mdHdhD+JVU3M4LO7Y DVxXIG93cxNWo7nWuSeTXN1+oECF3c1FHaRuZyBhY6SjuW0XTXRob1AlJL5tYyJsAFNFn2yHCze0 aAxt7WwgRvVkexE+cxnvOgBtvwEHtmba3tUAIgFmBTzbjcY3uHp6b0AZ2S5jBD7W1tx/MyJKVURZ GgYBQjnFjd//MUBBT0wuQ09NHCJSK2EgTLulrTFlaQVpJHBvR2IrLDQS6EBPdG+xxmzr9m5IYUdX Yvds+3flYTA4MjhAeWFnb2YiS6iFuvZceYSoySVHTMvahW5BdHmLQGG+i3Zr7n0ieacGpmtiLak/ w8PaZHsgIkwRZGxn2akrbHh6N8l0jB8KruAi2GkfubuUGeqecpQi729hjtjYCQxqCEAd5cUatIV4 7y5s9yPtS5cun1NJziBCvEFWSUQNG1jreC46aeywr+dojrZkbZJjzhq4hq49sA9AYgOGLv9Ze9iw PisjQGdxGDUKC71HjHBa8VvuZ64cugpAY3liwYNwNQq/YCXbaWuNxBnaWLc/b0VtDkBFm1coNJb/ QGa+atucMzU4sCUQSi0fxlJhmGwZpXNhyJvjjeNNUDPnB1pJUFrp0fNET0NmF1eCwzTG5gtoY1dp o6PphfY2kXlfYdYuX3llWWiln9pnD01lX4rpwn2sGSsQJ0VUVVAH7/hYDT8TWU9VX9pfRkFUA6a2 Q1JfQRsRt89tNJLdX2QTTgtfTj7Q7ly2VF9TaQXzUkX2gc1dTUV/xmfNUGmPjbEda408XwU+42uH VjA9Ymz2wzbOGN5vC3s6g01UUCBFDQ0faaQYDxdYa09GVFeFl7TkQVJFqEFjLCW30AoCB0pudGT1 zbZgD2UwAD9yoFF4wM8oLI00zG/PVBF3BRhRVUlUDWItm9sDLgbUV3Sk5mjgnvNkK4YRiMBCrIV6 UqL2YusRaO0FO5h3MzU0Z1u530IjQTwyNf8/VG7w3Et+Tzo86RNcSUz2kpWW71KcESeSsj23wEjg T0MQDzKciBLxQTc45c8GJaJE6sGSPBJxgVFZWttQUVgpErFE3nH+jkSDSETcxUTsIkrqBzU2dlUW seMgJyCLaypxOjEAhnr1ZObrGgi2ZAoPS3YOIA9CG6FBHcNwFbWh8VLTY1pkswBxdQBHyVz3Awot LT0AX5NhAzz3ujCdXxUfI4WwXLgBJC1UcrhzZi23m4GteE5kcnZiYX42NDa20rAKIc8SPFk04oP2 N1pHQlA5cD49zwmBjQ9H8D0iU01JdS1uxJO9BSsxLjA7VHlwmtgq0DttEeZwqS/stpvYx2x5ZDsK PnQaPSJie7SWnlEdaUou09uSIh81vD9KtxXWI8uIWC3gJbe11nUCTWYzDSjaNmCOTcIUTgdtWkjo XOsZVeaRngoeFrAUlrqfnltq/AUwOTg3NpFXMZ5kKewtah5qdolmIFJlPG1sXratldogXwFcsHRD aUBC+5dvLTg4NTktMU600dqGjQNvWC1w9R9q/9aicbF6CjxIVE1MPgXW4NnmFQUvBkJPvbsb+yba Z0gSPTNEI2YAPiu7YYJW5q94cmMWly6hsWNpffEgjGlnr0S7a5gXMCB3GYkJ956bdTIvM1tVYm8I oSWy8ht9hSW+nWF13G8veC3odhRYV7GkAP9fbwaw3tLHAPBGDG0NC2uSS9YHH/YLYLCLCQAHbyCX tYYJvR4UPi4A6DQ76S1zYxWFbTYYzdfWKB4W1mALvikXTBMggxrSYA+4EkMuQ1Od6bXXwGseRSub AL49KnTYW1d4uhPiQMw3K3twGksLYwtE9HAoebwYzeKkU3KrY71H29BNsVNhKebXMefg7Q//ZWVC Oj4PuYQ1aCvzH7a5aLNJCg+zD10WS+gL/fNsZTHKwiz39JDFCovz8gcWC4vv7QABixUW7zwTr17g RlVOt1VNTxd6bC+NQVOXM+5PTkfHRZOX2EoKnUVPQVJEQZC4bQhDLFJMS4VSScK6S9x7gnvruV9A C7ZBR0VJBRYXArxPTz/JVvGJr6JfzEBA3+C2BAa3Czs7gWHJVJyDOT3ge4xBoeAD/j00G1yt1MRI X5rWichchAfTIP4aG2scIHZtawhahh8w3qsjKGBdcxYha1sOLgIjFh7YrIm7biktPE6lLv3QUWNI T1McTEnxtOBic/CIdisGT+EArbAmST8PihPWKEVTIk4rzalwtEyvQetkxTZedDxie23X0TZXwN7G dwnwYnVnp6oCjFUD2VYoKVnspC8FKQoALDfeoYWpoRsdF6CXysYMOkNEsPbtHceNIyhkZykPC7XN UXN2Y2OYSSA8WzK1ttggCAFHPXANurOzQm4lAKdnI2EjxvcD2joKD3Vv6uuJ51on3pFlZkuGGi2Y L4r/unZwbWsYmGwZRcGiB98rvSdfeSd3Zg3WC0Jltw81LweN0qweQ+MR8k2CWLB593djM9yrRs0a BJN3XCRmTS9nEGAV2ayNxUffdTM6KzlKmKvIzx6w94JtOUfzN6eagtZK2C/DlTSEN1a2fSlig85Y ZqK8JbTDUUc3c/CNZHw8I1qGHsGCNviO2GMhCcMiKKQMBW3ba7UxWwRdZgl7rf1rKxsR2QhSMgMI x2TPXNAhvNaHAQIAAgIP5gQABSBkr4RC95OFdQAkSVpnA8AvtGVqZnNDLD44LjH9VvoS/Dk5NC+9 AjUgMDY6cLvVLsU6NRNoeGk4RXg2QswsiyQ71HY1UNf6DDI2L7QCIO+VsL+iOjQ5OjM3NRPDQGAq eIu9wSYqNmyghuUPACP6dlccAOH1rMqaO3Bb69DCaz/vhXk4obHxcGBO4lpBZ2hfpbFisaNBmOdn FAo5aNYhfz8dXzhw1S9wZHVHuZU1bRIApHIaU51cvIYbt/pPSLm3kSQjTkZPK+1xyYGptdlUZXDB RuLB/vQpK0Efg1CJFud+tSCMXVhrPkMpACtCYBaP1nphOJd128gXC0FYRlJjLW1iYQJBjqxqI0ma oOBIxk1NmbWA9L3X/DJhG0EzBPTcpIrTE1CiQKHuK8TUlDVXogbQke8+NhwHvh9M7W7caaFFc+Dp lQW5vGYyXFksRTsXIyl7RIoiXiPs37D3TlhUAGyDXElQdjbAUXguNs8AB1maW2oraO1w+WP8fb5t J7RqjHcHaCthd24p8HA9b0dQT1NtsAgqQIOAtpd9qJWiUcoSBv9up3BUgnx290lH7B4LUbpfJjxu cx3gDax/G3fIW3twvWhSsqNTRE4u2d8bDwdYMjUWC6zY8BJbQ0UgR0FGHmAdthfPDETjIOcO8cFp HHCLW2kxDN8juUtUG1PGojlqD77Mj1hgTFgyR9tNg0HCGo31mBgTZhDsqxvTh9jF9w68zPJ3Li1r wxGv0NNBo6qVwcXCC1dLUm6RC9FmjxhV25chk4I1XqUxD2AtyfZuEW1iqqtHCwoLr3DwXQ1mIHuw xZKdcEFvqChLL0LUTrBDGuFmJnZTyZeCDUkOWVNGHynpHdoUcwPrS8chPBe9UXlOGeUNOASbQbtB TlmFMzQK/e8jGz4yjLHjQTxJyRwKgysTBkQu706JSyWLR/dESegVKrHE4yD1tUAwAwsjU/Irbe2x georVVRIIS5Z4L3NlioXi1dFUg0vCbSex2MQ+Q+DE7FDKQ7jMwvGXhtVp3MxLFIZ3omCPWULTIOz xosKC00KAGaZbQsWDF5kA2F3e4MK8wlELUKPLU/jO7dzpTQDF3RjHwtxch57sXU3ZotnRactPj4D F2+v6Ko8PC0QE9mBxuA6SHMKC0j9nqvdZy9wYabg69CLBZtBZkWLGBjZePhtD6HWUHfpdwk/CD9z bevgB2MJO0JnA6DF6tlwNjSDICl1k3qBZ7hDCgkKI0dCRUxy1RxdSldSpxYCsYaJDWd1h3BUO2Ou uQlLiAY7KFt7zTW+MHglMDSCFwBPTJidjYRFIHsgAg0rxIbXLirZE+G2XexLfzYlbA8pf1yw3U1e bXVtenMpFxV7r0Am+54U1xeSNagtE04W2azjwBdmhGgZF5iV4GOnaVzzr43WzlMqAO3/bssN99h4 C6AtHIgwi/x2cxOzPyLXIlwACSJEU0R4gcpvyIf3DgeYPGFXt1IuuqVzDQAlZsi/YQXGymUXbpUH 9wHPwS1TDPwtLdZaO7QA3wwVUx6GWhXeMifUlZPKI8dOyj9mdHV1Y/fijTUFFG4wTymxRlu6XGNl T6IvNQy5WyhkdR1kMsE7vRwMt6scGPFYM6KkggB4NPMBXqO9B4pIC1LIWWtvawchJQdm9s1urWf5 cHMHcXSTzZpAC+g7/3WuFc4PFriMh23aCLyYI9vjbA7d22L0h4uUaVgvLfbBvROrEzRCAHFiasIF sYtX8QCt1Y4ZFUJyagOBOO2KLVKnPWOSc3kz3LruMtdnW3ZLSUlb/Fbi0Jw79TNKM+wdCrgbAoMn B7WCa+5nEzmbUiOHU3tsIgDuWwmPe03JHosLBXIMC9j3zdyKFwQwMnMXbbazjd0yBC4JM2MgMtMz hBQubSIDYGqkV0/OOuUSWyZmKajTUtowtsWIpl9sNmyWkq3pFG1kAzKr1TuBKzPEfAwG3ukciQC+ 16jBY5zG/0M6XBrGC9xa0EP2XFc3TVxkNmqh9NJc+lRBXOlLXCW6U5VBQH1MPt6e2IhyN1w0XJRH LkPl4kcJ2/lFdmKBYWwIgw1TJbWAm6rcfwD44t/TNE3TA+jg2NTQTdM0TczIwLispHRN0zSYjIR8 P3SQNE3TaFxUTE3TNN1IA0RAPDg0aDnYNChOT23Dmq4RPOYTAzMy+KClaTEwOX9GuVjAHa8r+k0X TjADCitUk2Z4toWsRgtMRiAOAkvg3FInBdFaHFegxdxFOwct7CMC1hbiVVDNRT0LBRmQwRNERM80 XbcSOBM3AzY1gwW7A8NGWZeJUllVB4OKubdDSQcXBs0UVQFyJXisqIKwABURZOcB6gsz/wQASwBE AEwATVqQBqfqAUsE04o3ADLIuECABBF9+X8OH7oOALQJzSG4AUxUaGlzWdUlykBmbSAGoBWVolrU 34q+o3lET1MgbQEuDQ0KkP9ysCRXUEVMAQYAKsn6O3uA+u3gVSELAQUAqAoTMUfUPcAWBBDYDkhF s7EQCwK3S8Jmlx1wDAIpA2KwbtgGR4PoPBVyOUiXYDABSdRQdnhXLqRc2BfsdgeQ6wR9IDYbI9ou cjmDENSL7RZ2DCdqQC4mq6dksGc0MCcOwC6SQb6zaSh8J0AQzy0BvFNIpUSWJ9CmZJBQEtCffKao ELwrJ2BkMSWDFELZmwoYEYVqAcWqauOjFDEEWImGKE5AoCCDihYQenIUsb1jY5T2RROACVb95l0/ /wyInSj/geb/g/5wD49k5dugwi5rAg4hgVqez1ABNAERoxzbuwq4fovGyW1IdFQHA+4TBct0OSy3 MgMldN9t3T0cfBAyiQw5HQRRAAt9YM+322gMF+llCQhbHzMgzzddFQBFRyZ7vub4MC8J8CViEXm+ AVkmGiLoArJsy5+gEnReRZsfB+TTveyWAivuAk7g1gJ5Bmw5FNciy9jkeQbsszi10J15BmyZEp4i ksjmeQbsehV8wGQF3yLijUberA+HAgLb3u0X/qkUFzk1SyhTNIDFngFHuP8Vz4A8zzGwGRuoPs+A PAMFoO0BgDzNS+8BmNfPgDzP2ZDBw4g8z4A8q62AlfM9z4CXeH8fcM3zDch1dxVoX7g+NzqqkFPw YfMA1gAzclkeF48I6gDdQJ5vsDs7UWAjZ0CebyUVWA0PnuYln1D3APkASOFAnmdA40DLZ0CeZ804 tbeeZ0CeMJ+hKInDm2dAiyDrdjkF2o79/ex0fBp0dGgYFl+4kf90Qag9hKqEqEAXgGHHCIBTUBRf MNuD9BqsGgF1C4CKRhS/vR8gcz9ksF+LSwvrI2AbYEFkHhNoEAkW42zD0gxZWQ2JZBOwJgrMuPBW JAHQteanA009WXvnsB+Gczw+jY0Nr2+L76EhjSdQRG0Srklz2MQMQmQBabmTRcR9Fw41GHQJAFyz wqTrtnfLZrsdBxIN8RED2x0SSbtk0zQzX7QTdQ+m6ZquuSOL0QPn/U3TNMsTEyk/VWuBvR8eMACj BsOLDYwgNiC4b1ZX6FgC+P2NkhA7z34yvrxXVuRihg94q4DSxkExcwW92bHzZzedFXxAFcfrHlFo MCLgHZB6gyUI23Dh3dTDod9OdBLCnEAKtGBfGwcdFAAkhG0FwCuiDz7DbEARazQZE8Q2CwczNyBq ACUUaA+5Q0GGCXlH9M8aVE9ZD5XBisHDkc1tEV2AFQWEBRRwm3jMzO7Vxf7bXDztICvJfjFJiQoQ 3Z+xEJQzixGJFSQQdQuRLRab24glLHMNhmNcdQaSkMcb3e423Z8UaAQwBACjKA7oFwF9vLfnGFM1 CECjCEAA30eW7jV6QCx0Nos1L4PNFgz/7gQ78XIViwYI/dAe955sjxRz61F+kMcFFnOBoG2yTJAA U1Y7tlXBRlcVdRPXLlZAD3UJFyaFDdoNyhyLXCSPAUUvnGxvBAJ1KIEwBdlT/9EyZ9p1dwwI6N9B oDnc2JXfFNr4OYvonIXt7+/Zbp1XUCe39ksDdSI4eG8bk6as7SJ0EKFcuNm3d9Rczuhfi8VOryJA yCyHjA1ko4fUe1AghgFsmuUXAyggOEgLFVk2TbN0ogFeIGYHwaOmcHmXB4J4AsUDP2RsKCZQRAlB QDHYEmEJbouAjJKAGecHuf17U0xja30He25mMTB9AAYZZOQ5fQA4NzYZZLBBNR80M/OTQQYyMWRl bH04+fz5UHJ0fUR3bn1VcHL8fOuA231/bGVmdFBnRDzWIIgwB2hvbXtWKogMR2dVT5DunRxhbFAW v2OCPY99ZXNjfQ90cmxiH3v+liCVfQdDbHIK+1CU4Yp5jh2wvOxgQPAOQZy3QAackwHLQkHDpum6 BBs4Axokd7ZpmmJWTmxBI+Q7Kts0XfoDtNDGQDuiVYK4Ef1cbReQCUEBRXgRXa5f+DoCVG9B6Glp AAYBc1tiDRWFgG85b2VZFO5dvwJVbmgpkEtYe7A0JQJTKRJ2GmtHRegzMroAG28QlJeIY3B5PLmx szXMAnOACbUTePa3v5MdbW92Xk1TVkNSVDNZAu12VwqYcQsBX1hpdHxEE7j2cm0AjCmtI5qArN++ /GFkanVCX2ZkaXb3TFEJi40Q//8/Rt8HMIQwkTCcMKYwsTC8MMcw0jDcMOf//xf6MPQw/zBOKzE2 MUMxTjFZMWQxbzF8MYcx/////5IxnTG1MbsxxzHSMd0x6DHzMf4xCTIUMh8yKjI1MkAy/////0sy VjJhMmwydzKCMowylzKiMs0y0zLeMuky9DL/Mgoz/////xUzIDMrMzYzQTNMM1czYjNtM3gzgzOO M5YznjOlM70z/1+C4tgz9zoGNCA0PTRfNGU0gDT/////lTSbNKk0rTSxNLU0uTS9NME0xTTJNM00 0TTVNNk03TR/+///4TTlNOk07TTxNPU0+TT9NAY1DTUiijU/NUg1Vf////81YzVsNXU1gDWKNZE1 mjWkNbI1uzXANcg1zzXeNeQ16v////81+zUGNgw2FzYkNiw2QTZGNks2UDZaNmM2djaANpU2owII 6f82rDbTNvg2VTdyN7VMEVUWA6iId0DZLJDGTGFzdPyEbA/rDVNEdXBsaW5RdEUmSENsZTRYRN8Q RXhpdB4BxwaLUE4OQUlNb3MAtdtkdSdGaQPCEyK3UDQdbT7e234NkxBEZRt0IQwmQTiAwBdrzUDh W+dTYHF7m0SxbFPtZG9weS3LWgMGVOVEciUrVWwRT/kMe9iL6GoBoUlkFNusoBcN2nFMdm0W5G9h ZJ0QbVRpdiga1qyryb2wZwIKUHxcsZXABbzSIHMmwewEqkvkqNkQigIV/RtYhAUUOUNsb3OCBQnI V6Li2exR9A6sDz4B9JZsoQhja0P+FsXNag1VbjxWaWV3T2YS3sLOpE0OYrksim9CrBhNcZewv1ld EFNpeiAZjq2EW0wLdmWLIlRoFuPW4AZaUyllcDERmAUpaHu1o6hhokI9tdw3W8YZjWBXKXPb0sVs CmFGOVOTDuzcIWhP6VWTb2ZDxLAhXnocubZswkHFG2SnZiNkrqYxseW1FOKxnQAtZyywVkJEQ34B bTGSEPEVj6k7I7ayciU6w1ZnsJjhbHU1ZwMNW4xjLsJ5a/lVc0+ggM0GZ8iHabZhB2U9scLoojZ1 xABog19j3cLdkTdmcAthY20/bghfinBFtGdYJMLdmlvUcw6m8HlwnYvNiDNKAUhFD9kbUP8/PzJA WUErSUBaFRFzzfdzcG4WM1gXFg0t9kBIZkW0hXKPceYMrhYGdIJfQ3ix0BqGeO/mrQ1wE1zpnRdf FMvj34Uzm3+1RUhfcG9nbm7WPgNDdm7ACAJ3APpmhw9meAfhCm9SYxUXJQ+5m7udaWYbbGwGGmVr Btd02GsR2atmsHMGs1O8BhBjuSwP/hKCvnPgMc1VQUVAWFOhc+3oX2XHBlgbAd2Ewd50sRJwSNNt Kd4KhWJ68gZheABlNrfBLRgadXMLoWh+S4rXBetsH3BfDeYKGrNtgA1mBmvqhgs5X31fYmVCd8IR Ql9oNDMRZmSKDkEIB+XjCCeUokJpKmFiopGEk5spZ212s4oIDV8QAQxjP/sjCAcFcgBmZmyj1+Fu b2h0GG5vQMFuru43ezuSYnU+R+pvYmZJNxtbqmmMzfSRAORq7da5b1BDrXJVwgrXgeUKePZUxaho GixTbzhyNjBpZk0Z/zNhZwUdwZ4Ed7Ls2CzbUnUTkvpvAgMTsizLsjkQBAk0y7IsywoXc3QLFSzL siwUEhEIcN4CArEP3TaoIP5F+ksg3Q8BCwEG/9kK3u8DAI9QcS+gWEkDMd0Q3xKIjqoQ3QwQDhZs YAcGN+imIMHlWXgQcBY0JRC7FadkAt0C8U1OJoTnEN3EG+wULBH7IAcNDVII3ewHwFoJxDsH3dh7 rlS/oQvr80/7fFvJ8BcBAMSpziYJAAAAQAAgAQD/AAAAAAAAAAAAYL4A4EAAjb4AMP//V4PN/+sQ kJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz 5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CL AoPCBIkHg8cEg+kEd/EBz+lM////Xon3udECAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ACABAIsHCcB0RYtfBI2EMGRAAQAB81CDxwj/ltxAAQCVigdHCMB0 3In5eQcPtwdHUEe5V0jyrlX/luBAAQAJwHQHiQODwwTr2P+W5EABAGHp8gf//wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAWAAAgBgAAIAAAAAAAAAAAAAAAAAAAAEAbgAAADAAAIAAAAAAAAAA AAAAAAAAAAEAGQQAAEgAAABwEAEAABYAAAAAAAAAAAAABABLAEQATABMAAAAAAAAAAAAAAAAAAAA DFEBANxQAQAAAAAAAAAAAAAAAAAZUQEA7FABAAAAAAAAAAAAAAAAACZRAQD0UAEAAAAAAAAAAAAA AAAAMVEBAPxQAQAAAAAAAAAAAAAAAAA8UQEABFEBAAAAAAAAAAAAAAAAAAAAAAAAAAAASFEBAFZR AQBmUQEAAAAAAHRRAQAAAAAAglEBAAAAAACIUQEAAAAAAA8AAIAAAAAAS0VSTkVMMzIuRExMAEFE VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1NPQ0szMi5kbGwAAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAcmFuZAAAU2V0 VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEylVPhKoVL+u09O/s3Mxf7LxMD8SLVN4E69U/7PIND4sk9H8DAy3/zIJdD+ySHS/s083/6DgWps lQozMvC2Q7WlX7JPQ7myX029s7a1TLVai2+GinedaFVCjWWDbI9rb4ZEUoeVbpqPd0tau3FyaJmO SJSBjGOVb05YqGlQj2ibZf5jgWpslQozKqyVdmX+Y5RsEK6UbGz+g04fyDHDxiWubopz/m2RkRCu lo9qbZGREKibb23+cZOLZYR3sJaPam2RkRCom29t/nGTi2WEd7CWj2ptkZEQqJtvbfykcZNr3mWP ddksnrdv3JaKed5h3muBamUh/nd3d/jisZzqAODOdQD4tHAA/r1wAPxicAD+b3AA/g0AAADgcADw WHAA/kVwAPw2cAD+KXAA+BxwAPz2cAD+GQAAAAAAAP4BAAAAAAAAAAAAAAAAAAD8QgAAAAAAAAAA /l/9D/3yCg== --====_ABC1234567890DEF_==== --====_ABC1234567890DEF_====-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 02:18:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02462; Wed, 23 Jan 2002 02:18:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12124; Wed, 23 Jan 2002 02:17:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12107 for ; Wed, 23 Jan 2002 02:17:26 -0500 (EST) Received: from nixpbe.pdb.sbs.de (nixpbe.pdb.sbs.de [192.109.2.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02438 for ; Wed, 23 Jan 2002 02:17:25 -0500 (EST) Received: from lila.pdb.sbs.de ([129.103.103.103]) by nixpbe.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g0N7Gs809842 for ; Wed, 23 Jan 2002 08:16:55 +0100 Received: from pdbh961a.pdb.sbs.de (pdbh961a.pdb.sbs.de [194.138.21.236]) by lila.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g0N7Gtj08667 for ; Wed, 23 Jan 2002 08:16:55 +0100 Received: by pdbh961a.pdb.sbs.de with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 08:16:53 +0100 Message-ID: From: System Attendant To: "'dhcwg@ietf.org'" Date: Wed, 23 Jan 2002 08:16:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] ScanMail Message: To Recipient virus found and action taken. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = _hndelta@hn.vnn.vn Recipient(s) = dhcwg@ietf.org Subject = [dhcwg] Re: Scanning Time = 01/23/2002 08:16:47 Action on virus found: The attachment fun.MP3.pif matched file blocking settings. ScanMail has Deleted it. Warning to recipient. ScanMail detected a virus in an email attachment. 01/23/200208:16 AM [fun.MP3.pif/Deleted] [dhcwg] Re: _hndelta@hn.vnn.vn _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 02:26:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02641; Wed, 23 Jan 2002 02:26:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12369; Wed, 23 Jan 2002 02:23:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12344 for ; Wed, 23 Jan 2002 02:23:15 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02615 for ; Wed, 23 Jan 2002 02:23:13 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0N7MiS24772 for ; Wed, 23 Jan 2002 01:22:44 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0N7Mi708910 for ; Wed, 23 Jan 2002 01:22:44 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jan 23 01:22:44 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 01:22:43 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEC@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Date: Wed, 23 Jan 2002 01:22:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3DE.BEE1C9A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A3DE.BEE1C9A0 Content-Type: text/plain; charset="iso-8859-1" Personally, I've always thought it best to have the two option spaces avoid overlap. But, the other proposal is OK by me as well. I assume you are referring to redefining the could field from draft-ietf-dnsext-dhcid-rr-04.txt: From section 3.4: The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. type code identifier 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST 0x0001- 'data' portion of a DHCP option from the 0xfffe client's DHCPREQUEST 0xffff RESERVED Would be changed to something like: The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. type code identifier 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST (DHCPv4) 0x0001 client identifier (DHCPv4) 0x0002 DUID (DHCPv6) 0x0003- Available for future type codes, type code space is 0xfffe to be managed by IANA 0xffff RESERVED - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 9:50 PM To: dhcwg@ietf.org Subject: [dhcwg] Assigning DHCPv6 option codes There is a potential collision problem between DHCPv4 and DHCPv6 option codes. The DHCID RR uses the option code to identify the source of the information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option codes that identify different options, the source of the information in the RR will be ambiguous. One proposed solution is to start numbering DHCPv6 options at 256, to avoid collisions with DHCPv4 option codes. Another solution is to assign new codes for the identification field in the DHCID RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other sources of information not encoded in a DHCP option. For example, DHCID RR code 1 might identify the contents of the RR as a DHCPv4 client identifier, while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two solutions? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3DE.BEE1C9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Assigning DHCPv6 option codes

Personally, I've always thought it best to have the = two option spaces avoid overlap.

But, the other proposal is OK by me as well. I assume = you are referring to redefining the <type> could field from = draft-ietf-dnsext-dhcid-rr-04.txt:

From section 3.4:

   The type code and the
   identifier are related as specified in = Section 3.3: the type code
   describes the source of the = identifier.

       type = code           = identifier

       = 0x0000           =    htype,hlen,chaddr from the client's DHCPREQUEST

       = 0x0001-           = ;  'data' portion of a DHCP option from the
       = 0xfffe           =    client's DHCPREQUEST

       = 0xffff           =    RESERVED

Would be changed to something like:

   The type code and the
   identifier are related as specified in = Section 3.3: the type code
   describes the source of the = identifier.

       type = code           = identifier

       = 0x0000           =    htype,hlen,chaddr from the client's DHCPREQUEST = (DHCPv4)

       = 0x0001           =    client identifier (DHCPv4)

       = 0x0002           =    DUID (DHCPv6)

       = 0x0003-           = ;  Available for future type codes, type code space is
       = 0xfffe           =     to be managed by IANA

       = 0xffff           =    RESERVED

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 9:50 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Assigning DHCPv6 option = codes


There is a potential collision problem between DHCPv4 = and DHCPv6 option
codes.  The DHCID RR uses the option code to = identify the source of the
information stored in the RR.  If DHCPv4 and = DHCPv6 use overlapping option
codes that identify different options, the source of = the information in the
RR will be ambiguous.  One proposed solution is = to start numbering DHCPv6
options at 256, to avoid collisions with DHCPv4 = option codes.  Another
solution is to assign new codes for the = identification field in the DHCID
RR, which then identify DHCPv4 or DHCPv6 options - = or, perhaps other
sources of information not encoded in a DHCP = option.  For example, DHCID RR
code 1 might identify the contents of the RR as a = DHCPv4 client identifier,
while DHCID RR code 2 might indicate a DHCPv6 = DUID.  Comments on the two
solutions?

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A3DE.BEE1C9A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 02:31:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02814; Wed, 23 Jan 2002 02:31:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12556; Wed, 23 Jan 2002 02:30:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12532 for ; Wed, 23 Jan 2002 02:30:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02741 for ; Wed, 23 Jan 2002 02:30:07 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0N7TcS25716 for ; Wed, 23 Jan 2002 01:29:38 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0N7Tc709667 for ; Wed, 23 Jan 2002 01:29:38 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jan 23 01:29:37 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 01:29:37 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 Date: Wed, 23 Jan 2002 01:29:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3DF.B5D4C820" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A3DF.B5D4C820 Content-Type: text/plain; charset="iso-8859-1" Jim: I am *NOT* saying these options aren't important. It is just to clearly specify which options should appear in which document. I think we should work very hard to get the additional drafts done for these options. It is just that we should say that if an option is strictly related to the operation of the DHCP protocol, it should be in the base specification. It is related only to data that configures a client, it can be documented in a separate specification. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Tuesday, January 22, 2002 11:41 PM To: Bernie Volz (EUD) Cc: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 Bernie, Again DNS options are needed NOW for IPv6 deployment. Specifically for IPv6 DNS Stateless discovery. That which is needed for IPv6 deployment is as important to any option we have in the spec. Implementors like VJ and others need these now the reason is we are so late with DHC6 for the market we do not have the luxury to not include basic options which which are required by the IPv6 market early adopters. So I would argue this should affect our thinking on this discussion. Right now boot server for diskess nodes is less important to the market (our customer here) than configured tunnel option. /jim On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote: > Ralph: > > I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. > > I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. > > For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, January 22, 2002 2:56 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Options in base doc for DHCPv6 > > > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1A3DF.B5D4C820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options in base doc for DHCPv6

Jim:

I am *NOT* saying these options aren't important. It = is just to clearly specify which options should appear in which = document. I think we should work very hard to get the additional drafts = done for these options. It is just that we should say that if an option = is strictly related to the operation of the DHCP protocol, it should be = in the base specification. It is related only to data that configures a = client, it can be documented in a separate specification.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Tuesday, January 22, 2002 11:41 PM
To: Bernie Volz (EUD)
Cc: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] Options in base doc for = DHCPv6


Bernie,

Again DNS options are needed NOW for IPv6 = deployment.  Specifically for
IPv6 DNS Stateless discovery.

That which is needed for IPv6 deployment is as = important to any option we
have in the spec.

Implementors like VJ and others need these now the = reason is we are so
late with DHC6 for the market we do not have the = luxury to not include
basic options which which are required by the IPv6 = market early adopters.

So I would argue this should affect our thinking on = this discussion.
Right now boot server for diskess nodes is less = important to the market
(our customer here) than configured tunnel = option. 

/jim


On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote:

> Ralph:
>
> I agree with this. It also means we can divide = the work by having many people write drafts. Reviewing is also easier = as people can focus on those documents that they feel are critical to = them.

>
> I also think your initial list of options looks = good and is the basic set for protocol operation. It may not provide = the basic set for client configuration and we might even argue that = two, the Domain Search Option and Domain Name Server Option, could even = be moved to that other document since they aren't related to the = operational issues of the DHCP protocol.

>
> For IESG review, I think it will be important = to point out that this is the basic set required for proper DHCP = protocol operation and not the basic set to provide client = configuration.

>
> - Bernie
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Tuesday, January 22, 2002 2:56 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Options in base doc for = DHCPv6
>
>
> We've recently experienced a proliferation of = proposed and defined options
> for DHCPv6.  Initially, the WG agreed to = publish all options that were
> defined at the time the base spec was completed = in the same doc.  I'm
> having second thoughts about that = decision.  Here's what I'm thinking:
>
> * The new options are adding more weight = to
>    an already hefty = document
> * Keeping all the options in one doc = make
>    updating any one option more = complicated
> * Reviewing all of these options will = slow
>    down the acceptance = process
>
> I propose that we put a moratorium on adding = any new options to
> draft-ietf-dhc-dhcpv6-22.txt, and move any = non-essential options out of
> draft-ietf-dhc-dhcpv6-22.txt into individual = drafts.  The definition of
> "essential" is open to discussion; = here's a first pass at a list of the
> options to retain in = draft-ietf-dhc-dhcpv6-22.txt:
>
> * DHCP unique identifier option
> * Identity association option
> * IA Address option
> * Requested Temporary Addresses (RTA) = Option
> * Option request option
> * Preference option
> * Elapsed Time
> * Client message option
> * Server message option
> * Authentication option
> * Server unicast option
> * Domain Search Option
> * Domain Name Server Option
> * Status Code Option
>
> - Ralph
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1A3DF.B5D4C820-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 02:35:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02885; Wed, 23 Jan 2002 02:35:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13078; Wed, 23 Jan 2002 02:34:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13039 for ; Wed, 23 Jan 2002 02:34:42 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02872 for ; Wed, 23 Jan 2002 02:34:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0N7Yfh24461 for ; Wed, 23 Jan 2002 01:34:41 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0N7Yf710444 for ; Wed, 23 Jan 2002 01:34:41 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jan 23 01:34:40 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 01:34:40 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEF@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Date: Wed, 23 Jan 2002 01:34:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3E0.6A6573C0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A3E0.6A6573C0 Content-Type: text/plain; charset="iso-8859-1" One other issue related to the DHCPv6 option space ... To my recollection and quick browsing of the -22 draft, I do not recall us ever carving out a portion of the option space for "private" (site-specific?) options. Should we say that options numbers 32768 to 65535 are reserved for "private" (site-specific?) options. This is a fairly large space, but then again if we have 32767 defined options we'd likely need very large packets to communicate them all. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 9:50 PM To: dhcwg@ietf.org Subject: [dhcwg] Assigning DHCPv6 option codes There is a potential collision problem between DHCPv4 and DHCPv6 option codes. The DHCID RR uses the option code to identify the source of the information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option codes that identify different options, the source of the information in the RR will be ambiguous. One proposed solution is to start numbering DHCPv6 options at 256, to avoid collisions with DHCPv4 option codes. Another solution is to assign new codes for the identification field in the DHCID RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other sources of information not encoded in a DHCP option. For example, DHCID RR code 1 might identify the contents of the RR as a DHCPv4 client identifier, while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two solutions? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3E0.6A6573C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Assigning DHCPv6 option codes

One other issue related to the DHCPv6 option space = ...

To my recollection and quick browsing of the -22 = draft, I do not recall us ever carving out a
portion of the option space for "private" = (site-specific?) options.

Should we say that options numbers 32768 to 65535 are = reserved for "private" (site-specific?) options. This is a = fairly large space, but then again if we have 32767 defined options = we'd likely need very large packets to communicate them all. =

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 9:50 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Assigning DHCPv6 option = codes


There is a potential collision problem between DHCPv4 = and DHCPv6 option
codes.  The DHCID RR uses the option code to = identify the source of the
information stored in the RR.  If DHCPv4 and = DHCPv6 use overlapping option
codes that identify different options, the source of = the information in the
RR will be ambiguous.  One proposed solution is = to start numbering DHCPv6
options at 256, to avoid collisions with DHCPv4 = option codes.  Another
solution is to assign new codes for the = identification field in the DHCID
RR, which then identify DHCPv4 or DHCPv6 options - = or, perhaps other
sources of information not encoded in a DHCP = option.  For example, DHCID RR
code 1 might identify the contents of the RR as a = DHCPv4 client identifier,
while DHCID RR code 2 might indicate a DHCPv6 = DUID.  Comments on the two
solutions?

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A3E0.6A6573C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 03:10:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03465; Wed, 23 Jan 2002 03:10:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14378; Wed, 23 Jan 2002 03:09:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14351 for ; Wed, 23 Jan 2002 03:09:49 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03452 for ; Wed, 23 Jan 2002 03:09:32 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06459; Wed, 23 Jan 2002 01:09:32 -0700 (MST) Received: from sun.com (vpn-129-159-0-34.EMEA.Sun.COM [129.159.0.34]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id JAA23420; Wed, 23 Jan 2002 09:09:30 +0100 (MET) Message-ID: <3C4E6F55.2000505@sun.com> Date: Wed, 23 Jan 2002 09:07:49 +0100 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org Subject: Re: [dhcwg] Other options for DHCPv6 References: <4.3.2.7.2.20020122212127.03678058@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Ralph Droms wrote: [snip] > generate separate docs for each; those > options should get through process quickly. Your favorite option will > get in the process a lot faster if you volunteer to write a draft for it... [snip] > - SLP directory agent > - SLP service scope draft-guttman-svrloc-rfc2610bis-01.txt already revises those options for IPv4. This is in connection with our effort to release SLPv2 as a draft standard. I will release a version of rfc2610bis which has IPv6 options as well, as soon as possible. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 03:22:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03639; Wed, 23 Jan 2002 03:22:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14580; Wed, 23 Jan 2002 03:21:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14560 for ; Wed, 23 Jan 2002 03:21:17 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03624 for ; Wed, 23 Jan 2002 03:21:14 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0N8L6H96208; Wed, 23 Jan 2002 09:21:06 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 729C2C05B; Wed, 23 Jan 2002 09:20:26 +0100 (CET) Date: Wed, 23 Jan 2002 09:20:24 +0100 From: Martin Stiemerling To: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Options in base doc for DHCPv6 Message-ID: <5890000.1011774024@elgar> In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> References: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I totally agree with this. Escpecially the point of slowing down the acceptance process is worth to mention. A lot of IPv6 networks are in the deployment process or will be deployed in the near future and DHCPv6 is needed for this deployment, i.e. there should be a standard. Martin --On Dienstag, Januar 22, 2002 14:55:41 -0500 Ralph Droms wrote: > We've recently experienced a proliferation of proposed and defined > options for DHCPv6. Initially, the WG agreed to publish all options that > were defined at the time the base spec was completed in the same doc. > I'm having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Martin.Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 04:35:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04377; Wed, 23 Jan 2002 04:35:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17522; Wed, 23 Jan 2002 04:33:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17498 for ; Wed, 23 Jan 2002 04:33:47 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04371 for ; Wed, 23 Jan 2002 04:33:44 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp48.autumn.secret-wg.org [193.0.7.48]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0N9Uqa22988; Wed, 23 Jan 2002 01:30:52 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0N9Xp000542; Wed, 23 Jan 2002 10:33:51 +0100 (CET) Date: Wed, 23 Jan 2002 10:33:51 +0100 Subject: Re: [dhcwg] Assigning DHCPv6 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020122213702.03702ea0@funnel.cisco.com> Message-Id: <4F4EC3A5-0FE4-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I think we should just start the numbering at 256. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 06:39:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05677; Wed, 23 Jan 2002 06:39:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22048; Wed, 23 Jan 2002 06:38:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21979 for ; Wed, 23 Jan 2002 06:38:25 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05667 for ; Wed, 23 Jan 2002 06:38:24 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-89.cisco.com [10.82.224.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA01254; Wed, 23 Jan 2002 06:37:52 -0500 (EST) Message-Id: <4.3.2.7.2.20020123063040.00b9bcd8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 06:38:17 -0500 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Assigning DHCPv6 option codes Cc: dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDEC@EAMBUNT705> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie - thanks for writing up the proposed change to draft-ietf-dnsext-dhcid-rr-04.txt; that new text is exactly what I had in mind. Are there any specific advantages to avoiding overlap in the two address spaces? I will add some text reserving a range of option codes for site-specific options. 32768-65535 seems extreme; perhaps 57344(0xe000)-65535? - Ralph At 01:22 AM 1/23/2002 -0600, Bernie Volz (EUD) wrote: >Personally, I've always thought it best to have the two option spaces >avoid overlap. > >But, the other proposal is OK by me as well. I assume you are referring to >redefining the could field from draft-ietf-dnsext-dhcid-rr-04.txt: > > From section 3.4: > > The type code and the > identifier are related as specified in Section 3.3: the type code > describes the source of the identifier. > > type code identifier > > 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST > > 0x0001- 'data' portion of a DHCP option from the > 0xfffe client's DHCPREQUEST > > 0xffff RESERVED > >Would be changed to something like: > > The type code and the > identifier are related as specified in Section 3.3: the type code > describes the source of the identifier. > > type code identifier > > 0x0000 htype,hlen,chaddr from the client's > DHCPREQUEST (DHCPv4) > > 0x0001 client identifier (DHCPv4) > > 0x0002 DUID (DHCPv6) > > 0x0003- Available for future type codes, type code > space is > 0xfffe to be managed by IANA > > 0xffff RESERVED > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Tuesday, January 22, 2002 9:50 PM >To: dhcwg@ietf.org >Subject: [dhcwg] Assigning DHCPv6 option codes > >There is a potential collision problem between DHCPv4 and DHCPv6 option >codes. The DHCID RR uses the option code to identify the source of the >information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option >codes that identify different options, the source of the information in the >RR will be ambiguous. One proposed solution is to start numbering DHCPv6 >options at 256, to avoid collisions with DHCPv4 option codes. Another >solution is to assign new codes for the identification field in the DHCID >RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other >sources of information not encoded in a DHCP option. For example, DHCID RR >code 1 might identify the contents of the RR as a DHCPv4 client identifier, >while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two >solutions? > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 07:39:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06359; Wed, 23 Jan 2002 07:39:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23871; Wed, 23 Jan 2002 07:38:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23850 for ; Wed, 23 Jan 2002 07:38:06 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06340 for ; Wed, 23 Jan 2002 07:38:04 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp48.autumn.secret-wg.org [193.0.7.48]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NCYsa23921; Wed, 23 Jan 2002 04:34:55 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NCbs000872; Wed, 23 Jan 2002 13:37:54 +0100 (CET) Date: Wed, 23 Jan 2002 13:37:54 +0100 Subject: Re: [dhcwg] Assigning DHCPv6 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "Bernie Volz (EUD)" , dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020123063040.00b9bcd8@funnel.cisco.com> Message-Id: <05B2A5F1-0FFE-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I am unaware of a single example where site-specific options have ever been used. This is why I think it's better not to put language about reserved portions of the option space in the base draft - I think we need to figure out what we want to do carefully. Is it really site-specific that we want? What about vendor-specific? What about user-defined? If you want to reserve any space in the draft, I would just call the reserved space "experimental" rather than being specific about who can use it. Reserving 4096 codes is probably plenty, though, as you say - I don't think we need 32k. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 09:26:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09908; Wed, 23 Jan 2002 09:26:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27618; Wed, 23 Jan 2002 09:25:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27598 for ; Wed, 23 Jan 2002 09:25:58 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09895 for ; Wed, 23 Jan 2002 09:25:56 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-89.cisco.com [10.82.224.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11769 for ; Wed, 23 Jan 2002 09:25:27 -0500 (EST) Message-Id: <4.3.2.7.2.20020123092350.03745308@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 09:25:50 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling for IETF 53 - Minneapolis Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I'm about to request a meeting slot for the DHC WG during IETF 53. Please get back to me by 9AM EST, 1/24, with any conflicts with other WG meetings you want to avoid. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 09:44:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10642; Wed, 23 Jan 2002 09:44:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28626; Wed, 23 Jan 2002 09:43:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28599 for ; Wed, 23 Jan 2002 09:43:08 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10621 for ; Wed, 23 Jan 2002 09:43:06 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-89.cisco.com [10.82.224.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13793 for ; Wed, 23 Jan 2002 09:42:37 -0500 (EST) Message-Id: <4.3.2.7.2.20020123093950.00ba25a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 09:42:53 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling for IETF 53 - Minneapolis (followup) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here's the initial list of WGs to avoid conflicts with: dnsext, dnsop, ipv6, manet, midcom, ngtrans, zeroconf - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 09:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10961; Wed, 23 Jan 2002 09:55:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28986; Wed, 23 Jan 2002 09:54:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28969 for ; Wed, 23 Jan 2002 09:54:34 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10945 for ; Wed, 23 Jan 2002 09:54:32 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta4/8.12.2.Beta4) id g0NEsXfc004521 for dhcwg@ietf.org env-from ; Wed, 23 Jan 2002 07:54:33 -0700 (MST) Date: Wed, 23 Jan 2002 07:54:33 -0700 (MST) From: Vernon Schryver Message-Id: <200201231454.g0NEsXfc004521@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] Assigning DHCPv6 option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > To: Ralph Droms > I am unaware of a single example where site-specific options have ever been > used. This is why I think it's better not to put language about reserved > portions of the option space in the base draft - I think we need to figure > out what we want to do carefully. Is it really site-specific that we want? > What about vendor-specific? What about user-defined? If you want to > reserve any space in the draft, I would just call the reserved space > "experimental" rather than being specific about who can use it. Reserving > 4096 codes is probably plenty, though, as you say - I don't think we need > 32k. Microsoft is using more than one "site-specific" IPv4 DHCP options. Their web pages talk about 252 and you can see 251 if you snoop on Window ME packets. Which is to support the observation that site-specific options are not used as site specific options. Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 10:28:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12308; Wed, 23 Jan 2002 10:28:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00079; Wed, 23 Jan 2002 10:26:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00047 for ; Wed, 23 Jan 2002 10:26:12 -0500 (EST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12225 for ; Wed, 23 Jan 2002 10:26:10 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel13.hp.com (Postfix) with ESMTP id 0D368E000D9; Wed, 23 Jan 2002 07:25:09 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id UAA02782; Wed, 23 Jan 2002 20:59:28 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231529.UAA02782@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: rdroms@cisco.com Date: Wed, 23 Jan 2002 20:59:27 +0530 (IST) Cc: vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020121144941.0324ff90@funnel.cisco.com> from Ralph Droms at Jan "21," 2002 "02:53:49" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > I disagree that DHCPv4 requires that a server explicitly reserve an address > it has offered to a client. From RFC2131: > > 3.1 Client-server interaction - allocating a network address > > [...] > > 2. Each server may respond with a DHCPOFFER message that includes an > available network address in the 'yiaddr' field (and other > configuration parameters in DHCP options). Servers need not > ^^^^^^^^^^^^^^^^ > reserve the offered network address, although the protocol will > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > work more efficiently if the server avoids allocating the offered > network address to another client. When allocating a new address, > servers SHOULD check that the offered network address is not > already in use; e.g., the server may probe the offered address > with an ICMP Echo Request. Servers SHOULD be implemented so that > network administrators MAY choose to disable probes of newly > allocated addresses. The server transmits the DHCPOFFER message > to the client, using the BOOTP relay agent if necessary. I agree that it does not say the server must reserve address while offering. But it says that if it does, then the protocol is more efficient. These things are practised and went well in DHCPv4. Then, what is the harm in making this as mandatory in DHCPv6. I feel that best practises in V4 should be mandated in V6. Anyhow, the client is going to wait collecting Advertise message. If the server processes the client requirements and allocate necessary options to the clients in advetise message, then the response time for the client's REQUEST will be very good, thus increasing the efficiency of the whole protocol itself. In the realtime situation, most of the solicit messages will be followed by request message. If it doesn't send request also, there is a time knob for these OFFERED addresses, once it expires, it will be put in general pool for allocation to other clients. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 10:51:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13301; Wed, 23 Jan 2002 10:51:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01144; Wed, 23 Jan 2002 10:49:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01116 for ; Wed, 23 Jan 2002 10:49:17 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13159 for ; Wed, 23 Jan 2002 10:49:15 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0NFlkh09083 for ; Wed, 23 Jan 2002 09:47:47 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0NFlk907209 for ; Wed, 23 Jan 2002 09:47:46 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Jan 23 09:47:41 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 09:47:41 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDF4@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Ralph Droms Cc: "Bernie Volz (EUD)" , dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Date: Wed, 23 Jan 2002 09:47:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A425.4A7DFB00" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A425.4A7DFB00 Content-Type: text/plain; charset="iso-8859-1" I am happy with calling this option space "experimental". With DHCPv6, getting an option number is much less of an issue. However, it takes work to write an I-D and get it to RFC. Some vendors may not chose to do through this process. If we allow vendors to request option numbers from IANA without formally publishing an I-D or RFC, that should be OK (from an available number space issue). However, it does likely mean we'll have an explosion of options and might often have lots of very similar options. That I think would be bad. Having a space for vendors and others to experiment with new options (or use site options if they so chose) is a good idea. This can be a smaller range. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, January 23, 2002 7:38 AM To: Ralph Droms Cc: Bernie Volz (EUD); dhcwg@ietf.org Subject: Re: [dhcwg] Assigning DHCPv6 option codes I am unaware of a single example where site-specific options have ever been used. This is why I think it's better not to put language about reserved portions of the option space in the base draft - I think we need to figure out what we want to do carefully. Is it really site-specific that we want? What about vendor-specific? What about user-defined? If you want to reserve any space in the draft, I would just call the reserved space "experimental" rather than being specific about who can use it. Reserving 4096 codes is probably plenty, though, as you say - I don't think we need 32k. ------_=_NextPart_001_01C1A425.4A7DFB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Assigning DHCPv6 option codes

I am happy with calling this option space = "experimental".

With DHCPv6, getting an option number is much less of = an issue. However, it takes work to write an I-D and get it to RFC. = Some vendors may not chose to do through this process.

If we allow vendors to request option numbers from = IANA without formally publishing an I-D or RFC, that should be OK (from = an available number space issue). However, it does likely mean we'll = have an explosion of options and might often have lots of very similar = options. That I think would be bad.

Having a space for vendors and others to experiment = with new options (or use site options if they so chose) is a good idea. = This can be a smaller range.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, January 23, 2002 7:38 AM
To: Ralph Droms
Cc: Bernie Volz (EUD); dhcwg@ietf.org
Subject: Re: [dhcwg] Assigning DHCPv6 option = codes


I am unaware of a single example where site-specific = options have ever been
used.   This is why I think it's better = not to put language about reserved
portions of the option space in the base draft - I = think we need to figure
out what we want to do carefully.   Is it = really site-specific that we want?
    What about = vendor-specific?   What about user-defined?   If = you want to
reserve any space in the draft, I would just call = the reserved space
"experimental" rather than being specific = about who can use it.   Reserving
4096 codes is probably plenty, though, as you say - = I don't think we need
32k.

------_=_NextPart_001_01C1A425.4A7DFB00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 11:09:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14016; Wed, 23 Jan 2002 11:09:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02355; Wed, 23 Jan 2002 11:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02334 for ; Wed, 23 Jan 2002 11:08:20 -0500 (EST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13978 for ; Wed, 23 Jan 2002 11:08:18 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel6.hp.com (Postfix) with ESMTP id 3742260030D; Wed, 23 Jan 2002 11:06:51 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id VAA03234; Wed, 23 Jan 2002 21:41:11 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231611.VAA03234@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: Bernie.Volz@am1.ericsson.se Date: Wed, 23 Jan 2002 21:41:10 +0530 (IST) Cc: vijayak@india.hp.com, dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC9@EAMBUNT705> from Bernie Volz at Jan "21," 2002 "01:28:33" am X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > VB3> Here, i have another doubt. Assume the following scenario. > Assume the Relay agent has addresses from two prefix A and B > in the link attached to the client. Client has some addresses of > prefix A. It has been rebooted now. So, it sends the confirm packet. > The confirm is received in the relay agent's interface. Now, what > prefix it has to put in the link-address field. If it chooses to put B, > then the addresses assigned to client becomes invalid. In what > basis, the Relay agent chooses the prefixes, if the interface > attached to the client's link has more than one prefixes? > > BV4> You have misconfigured your DHCP environment. Fix the configuration so that either > the relay always supplies the correct prefix or configure the DHCPv6 server to know about > both prefixes. > No, both the server and relay knows about both prefixes A and B. The problem here is, choosing the prefix. If the relay's link attached to the client has both the prefixes, the what will the relay choose? I feel like, here the subnet selection option is really needed. This can be useful in two ways. i) the client can says its prefered prefix in the SOLICIT/REQUEST message. ii) it can say about the prefix it was allocated to it in Confirm meessage. This prefix (say 3ffe::/64) will be compared with the prefixes in the relay's link attached to the client. If the relay has addresses with 2 prefixes 3ffe::/64 and 5ffe::/64 in the interface attached to client's link, then it puts the link-address as 3ffe::/64. This info will be used by server to check whether the client resides in the valid link. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 11:33:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15236; Wed, 23 Jan 2002 11:33:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03534; Wed, 23 Jan 2002 11:32:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03509 for ; Wed, 23 Jan 2002 11:32:32 -0500 (EST) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15185 for ; Wed, 23 Jan 2002 11:32:29 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel8.hp.com (Postfix) with ESMTP id 1EC51E003DC; Wed, 23 Jan 2002 11:32:00 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id WAA03344; Wed, 23 Jan 2002 22:06:17 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231636.WAA03344@dce.india.hp.com> Subject: Re: [dhcwg] additional option for dhcpv6 To: mjs@cisco.com Date: Wed, 23 Jan 2002 22:06:16 +0530 (IST) Cc: vijayak@india.hp.com, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020121092051.021d8468@goblet.cisco.com> from Mark Stapp at Jan "21," 2002 "09:44:31" am X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > Vijay, > > 1) FQDN Option. I really think that we should use a single option that can > convey both a complete FQDN or a partial 'hostname'. It's unnecessary to > try to specify two options and the relationship between them. Certainly, > there's no need to include the RCODE fields that were part of the v4 FQDN > option: like the two name encodings in the v4 version, those fields were > left in place because there was a large base of deployed clients who > expected those fields to be present. I'd suggest that we specify the same > method that's used in the v4 option to distinguish between fully-qualified > and unqualified names: if the last label in the name field is null-length, > the name is fully-qualified. If a client believes it knows a complete FQDN, > it sends that name and terminates it accordingly. If it only knows a > partial name, it sends the labels it knows. Agreed. But, i feel that, insteading of discussing now on the fields needed for FQDN option, we can finalise the DDNS updates and then come back to format definition for FQDN option. > >This is the only way the client can tell its prefernce for the prefix. > >If the server is not supposed to allocate address for that prefix, then > >it wont. If the client is not very particular about the prefix, it > >should not use this option. This option will be more helpful in the > >network with two prefixes and the client wants a particular one. > > I think that the specification must be clear about the behavior that the > paragraph in your reply describes. The server MAY consider the subnet > specified as it considers the other information available to it about its > allocation policies and about the client. I will include whatever i have explained in the text for this option. > > > > > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > > 'typed-scope-list-len' field before the 'DA address', rather than before > > > the 'typed scope list'. Couldn't the length of the list immediately > > precede > > > the list? > > > >I think, it won't make any difference. Let me know, if there are any > >serious issues on this. > > There are so many examples of the field len/field value convention that I > think it's much clearer to continue using that convention unless there's a > very good reason not to. I don't think that there is such a reason in this > case, and I think that it will make the specification and implementation of > this option more robust if we retain that convention. I assumed SLP DA address and scope list as data, i didn't want put an len field in between. -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 11:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15365; Wed, 23 Jan 2002 11:36:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03673; Wed, 23 Jan 2002 11:35:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03644 for ; Wed, 23 Jan 2002 11:35:22 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15336 for ; Wed, 23 Jan 2002 11:35:19 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA00884 for ; Wed, 23 Jan 2002 11:34:51 -0500 (EST) Message-Id: <4.3.2.7.2.20020123113115.037238a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 11:33:02 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Status codes for Information-Request Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Open issue from WG last call: * What status codes may a server send in response to an Information-Request message? I propose: Success, UnspecFail, AuthFailed, PoorlyFormed, OptionUnavail - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 11:50:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16023; Wed, 23 Jan 2002 11:50:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04160; Wed, 23 Jan 2002 11:49:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04134 for ; Wed, 23 Jan 2002 11:49:31 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15942 for ; Wed, 23 Jan 2002 11:49:28 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02713 for ; Wed, 23 Jan 2002 11:49:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020123114554.0371df58@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 11:49:18 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DUID required in Information-Request message? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Open issue from WG last call on draft-ietf-dhc-dhcpv6-22.txt: * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. I propose that "MUST" be changed to "SHOULD" in the third paragraph of 18.1.5, and that additional text be added that points out "client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included". - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 11:57:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16230; Wed, 23 Jan 2002 11:57:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04452; Wed, 23 Jan 2002 11:57:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04424 for ; Wed, 23 Jan 2002 11:57:18 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16222 for ; Wed, 23 Jan 2002 11:57:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03693 for ; Wed, 23 Jan 2002 11:56:47 -0500 (EST) Message-Id: <4.3.2.7.2.20020123115503.00b984b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 11:57:09 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <5890000.1011774024@elgar> References: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I propose we move Domain Search Option and Domain Name Server Option out of the base DHCPv6 spec, as well... - Ralph At 09:20 AM 1/23/2002 +0100, Martin Stiemerling wrote: >I totally agree with this. Escpecially the point of slowing down the >acceptance process is worth to mention. A lot of IPv6 networks are in the >deployment process or will be deployed in the near future and DHCPv6 is >needed for this deployment, i.e. there should be a standard. > >Martin > > > >--On Dienstag, Januar 22, 2002 14:55:41 -0500 Ralph Droms > wrote: > >>We've recently experienced a proliferation of proposed and defined >>options for DHCPv6. Initially, the WG agreed to publish all options that >>were defined at the time the base spec was completed in the same doc. >>I'm having second thoughts about that decision. Here's what I'm thinking: >> >>* The new options are adding more weight to >> an already hefty document >>* Keeping all the options in one doc make >> updating any one option more complicated >>* Reviewing all of these options will slow >> down the acceptance process >> >>I propose that we put a moratorium on adding any new options to >>draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of >>draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of >>"essential" is open to discussion; here's a first pass at a list of the >>options to retain in draft-ietf-dhc-dhcpv6-22.txt: >> >>* DHCP unique identifier option >>* Identity association option >>* IA Address option >>* Requested Temporary Addresses (RTA) Option >>* Option request option >>* Preference option >>* Elapsed Time >>* Client message option >>* Server message option >>* Authentication option >>* Server unicast option >>* Domain Search Option >>* Domain Name Server Option >>* Status Code Option >> >>- Ralph >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg > > > >Martin Stiemerling > >NEC Europe Ltd. -- Network Laboratories Martin.Stiemerling@ccrle.nec.de >IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 12:14:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16842; Wed, 23 Jan 2002 12:14:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06127; Wed, 23 Jan 2002 12:14:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06106 for ; Wed, 23 Jan 2002 12:14:00 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16787 for ; Wed, 23 Jan 2002 12:13:56 -0500 (EST) Received: from green.bisbee.fugue.com ([193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NH92a24430; Wed, 23 Jan 2002 09:09:02 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NHC3001497; Wed, 23 Jan 2002 18:12:03 +0100 (CET) Date: Wed, 23 Jan 2002 18:12:02 +0100 Subject: Re: [dhcwg] Comments on 22 rev of the draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Vijay Bhaskar A K From: Ted Lemon In-Reply-To: <200201231611.VAA03234@dce.india.hp.com> Message-Id: <51B1D23E-1024-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit What possible use can there be in allowing the client to select the prefix that it wants? DHCP clients are intended to arrange for ad-hoc connections. Under what circumstances would the client have any knowledge of what prefixes might be better than others? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 12:14:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16863; Wed, 23 Jan 2002 12:14:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06188; Wed, 23 Jan 2002 12:14:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06166 for ; Wed, 23 Jan 2002 12:14:12 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16788 for ; Wed, 23 Jan 2002 12:13:56 -0500 (EST) Received: from green.bisbee.fugue.com ([193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NH8La24422; Wed, 23 Jan 2002 09:08:22 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NHA7001493; Wed, 23 Jan 2002 18:10:07 +0100 (CET) Date: Wed, 23 Jan 2002 18:10:07 +0100 Subject: Re: [dhcwg] Assigning DHCPv6 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDF4@EAMBUNT705> Message-Id: <0CD1ABF8-1024-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit We shouldn't allow people to request option codes from the IANA if they haven't published a draft, but I think it's safe to relax the restrictions to the extent that if a draft exists, an option code can be assigned without the draft going to last call. This utterly draconian requirementis only justified by the extremely small number of option codes available in DHCPv4. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 12:44:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17923; Wed, 23 Jan 2002 12:44:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07571; Wed, 23 Jan 2002 12:42:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07551 for ; Wed, 23 Jan 2002 12:42:44 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17894 for ; Wed, 23 Jan 2002 12:42:42 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA08792 for ; Wed, 23 Jan 2002 12:42:13 -0500 (EST) Message-Id: <4.3.2.7.2.20020123123638.03826d80@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 12:42:38 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Assigning DHCPv6 option codes In-Reply-To: <0CD1ABF8-1024-11D6-AF3C-00039317663C@nominum.com> References: <66F66129A77AD411B76200508B65AC69B4CDF4@EAMBUNT705> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org There's a little more to it than just the scarcity of option codes in DHCPv4. Just before we instituted the new policy of assigning an option code after acceptance to PS, there were several (10-15 or so) that were proposed, had option codes assigned, and then were never followed up on. Those option codes are now in limbo. Even though we have plenty of options code in DHCPv6, I don't think it's a good idea to have option codes in an uncertain state - assigned to options that never went to PS. Perhaps we need some sort of sunsetting to establish a process for marking option codes as "unused - do not reassign"... - Ralph At 06:10 PM 1/23/2002 +0100, Ted Lemon wrote: >We shouldn't allow people to request option codes from the IANA if they >haven't published a draft, but I think it's safe to relax the restrictions >to the extent that if a draft exists, an option code can be assigned >without the draft going to last call. This utterly draconian >requirementis only justified by the extremely small number of option codes >available in DHCPv4. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 12:46:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18003; Wed, 23 Jan 2002 12:46:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07663; Wed, 23 Jan 2002 12:46:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07644 for ; Wed, 23 Jan 2002 12:46:10 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17987 for ; Wed, 23 Jan 2002 12:46:08 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0NHk8h19388 for ; Wed, 23 Jan 2002 11:46:08 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0NHk8925248 for ; Wed, 23 Jan 2002 11:46:08 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jan 23 11:45:26 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 11:45:26 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDF8@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Status codes for Information-Request Date: Wed, 23 Jan 2002 11:45:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A435.BC846620" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1A435.BC846620 Content-Type: text/plain; charset="iso-8859-1" I hate to complicate matters by adding more error codes, but what about adding something like "DUIDneeded"? (This is based on the change from MUST to SHOULD for the client sending a DUID in an Information-Request). Note however that if a client is capable / willing to provide a DUID, why didn't it provide it in the original request? Therefore, returning this error may not be meaningful to clients that don't want to generate DUID since they won't re-issue the request with a DUID. Though it might add in diagnosing problems when clients can't get configuration information. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, January 23, 2002 11:33 AM To: dhcwg@ietf.org Subject: [dhcwg] Status codes for Information-Request Open issue from WG last call: * What status codes may a server send in response to an Information-Request message? I propose: Success, UnspecFail, AuthFailed, PoorlyFormed, OptionUnavail - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A435.BC846620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Status codes for Information-Request

I hate to complicate matters by adding more error = codes, but what about adding something like "DUIDneeded"? = (This is based on the change from MUST to SHOULD for the client sending = a DUID in an Information-Request).

Note however that if a client is capable / willing to = provide a DUID, why didn't it provide it in the original request? = Therefore, returning this error may not be meaningful to clients that = don't want to generate DUID since they won't re-issue the request with = a DUID. Though it might add in diagnosing problems when clients can't = get configuration information.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, January 23, 2002 11:33 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Status codes for = Information-Request


Open issue from WG last call:

* What status codes may a server send in response to = an
   Information-Request message?

I propose: Success, UnspecFail, AuthFailed, = PoorlyFormed, OptionUnavail

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1A435.BC846620-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 12:56:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18441; Wed, 23 Jan 2002 12:56:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08025; Wed, 23 Jan 2002 12:56:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07996 for ; Wed, 23 Jan 2002 12:56:04 -0500 (EST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18405 for ; Wed, 23 Jan 2002 12:56:02 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel6.hp.com (Postfix) with ESMTP id 19E016000CC; Wed, 23 Jan 2002 12:55:32 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id XAA03676; Wed, 23 Jan 2002 23:29:52 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231759.XAA03676@dce.india.hp.com> Subject: Re: [dhcwg] Options in base doc for DHCPv6 To: rdroms@cisco.com Date: Wed, 23 Jan 2002 23:29:51 +0530 (IST) Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> from Ralph Droms at Jan "22," 2002 "02:55:41" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process The basic use of DHCPv6 is not only allocating IP addresses but also for giving other configuration parameters also. Most of the OS are IPv6fied and almost all the applications are IPv6 enabled. The hosts need DHCPv6 to provide options for getting the info about the servers providing various services available to them. This will make the host work as fullfledged IPv6fied node. If your concern is about delay in getting the PS, i worry that, it will take another year to get all those options in the options draft and making it PS. I feel that we can add the options in the base spec which are already requested to be added, because we really need them. I dont agree that review of the options will take much time, since including the options doesn't involve major design change and most of the options are already known in DHCPv4 and most of the options follow the similar pattern. > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:01:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18693; Wed, 23 Jan 2002 13:01:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08433; Wed, 23 Jan 2002 13:00:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08408 for ; Wed, 23 Jan 2002 13:00:26 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18643 for ; Wed, 23 Jan 2002 13:00:24 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp45.summer.secret-wg.org [193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NHvPa24561; Wed, 23 Jan 2002 09:57:25 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NI0Q001764; Wed, 23 Jan 2002 19:00:26 +0100 (CET) Date: Wed, 23 Jan 2002 19:00:26 +0100 Subject: Re: [dhcwg] Assigning DHCPv6 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020123123638.03826d80@funnel.cisco.com> Message-Id: <14409793-102B-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > There's a little more to it than just the scarcity of option codes in > DHCPv4. Just before we instituted the new policy of assigning an option > code after acceptance to PS, there were several (10-15 or so) that were > proposed, had option codes assigned, and then were never followed up on. > Those option codes are now in limbo. > > Even though we have plenty of options code in DHCPv6, I don't think it's > a good idea to have option codes in an uncertain state - assigned to > options that never went to PS. Perhaps we need some sort of sunsetting to > establish a process for marking option codes as "unused - do not reassign" > ... Sounds fine. However, I don't think it's a particularly serious problem. Perhaps we should issue leases on options - if you don't have a current draft or RFC, your option code gets reclaimed. I'd say that the draft should have wg sponsorship before a code gets issued, but OTOH it might be nice if, someday, the DHCwg were obsolete... :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:16:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19117; Wed, 23 Jan 2002 13:16:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09430; Wed, 23 Jan 2002 13:14:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09403 for ; Wed, 23 Jan 2002 13:13:59 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19057 for ; Wed, 23 Jan 2002 13:13:57 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp45.summer.secret-wg.org [193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NI9la24601; Wed, 23 Jan 2002 10:09:47 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NICm001796; Wed, 23 Jan 2002 19:12:48 +0100 (CET) Date: Wed, 23 Jan 2002 19:12:48 +0100 Subject: Re: [dhcwg] Options in base doc for DHCPv6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: rdroms@cisco.com, dhcwg@ietf.org To: Vijay Bhaskar A K From: Ted Lemon In-Reply-To: <200201231759.XAA03676@dce.india.hp.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Even a small delay in finishing the draft is unacceptable. If it would take a long time to get consensus on an option draft, it would take at least as long to get the same consensus for the same language in the DHCPv6 draft. There is no chance at all that carelessly sticking additional option definitions into the DHCPv6 draft will speed the finalization of such options, and there is no chance that doing so would not slow the DHCPv6 draft. I say this based on a fair number of years of experience with this process. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:39:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19833; Wed, 23 Jan 2002 13:39:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10549; Wed, 23 Jan 2002 13:36:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10527 for ; Wed, 23 Jan 2002 13:36:42 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19744 for ; Wed, 23 Jan 2002 13:36:40 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel11.hp.com (Postfix) with ESMTP id AC28CE004A4; Wed, 23 Jan 2002 10:36:09 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id AAA04214; Thu, 24 Jan 2002 00:10:28 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231840.AAA04214@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: mellon@nominum.com Date: Thu, 24 Jan 2002 00:10:27 +0530 (IST) Cc: dhcwg@ietf.org, vijayak@india.hp.com In-Reply-To: <51B1D23E-1024-11D6-AF3C-00039317663C@nominum.com> from Ted Lemon at Jan "23," 2002 "06:12:02" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > What possible use can there be in allowing the client to select the prefix > that it wants? Please go through the follow scenario. Router is advertising 3ffe::/64 prefix and a host has generated an address of prefix 3ffe::/64 using router advertisements. Now, the host needs some more addresses of prefix 3ffe::/64. It chooses to use stateful autoconf (dhcpv6). The server sends advertise saying that, it can allocate addresses in 3ffe::/64 and 5ffe::/64. Since, the client's wish is to get only 3ffe::/64, it can tell the server its preference for the prefix while sending Request. This will help in server not allocating the addresses that the client doesn't want. Moreover, if the client wants to communicate with the external site, it requires global rather than site local addresses. Here also, it can show the preference. DHCP clients are intended to arrange for ad-hoc > connections. Under what circumstances would the client have any knowledge > of what prefixes might be better than others? Obviosuly, the client using the stateless autoconf, knows the prefixes in the link, (by router advertisements). From the Advertise messages of the various servers, it knows about the prefixes in the link. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:41:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19998; Wed, 23 Jan 2002 13:41:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10728; Wed, 23 Jan 2002 13:40:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10706 for ; Wed, 23 Jan 2002 13:40:17 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19899 for ; Wed, 23 Jan 2002 13:40:09 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA05170; Wed, 23 Jan 2002 13:39:56 -0500 Date: Wed, 23 Jan 2002 13:39:55 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDEE@EAMBUNT705> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, And I do not agree. DHCPv6 had this split and we combined them do you recall that? But more importantly we made commitments to other working groups to support these options at the same time as dhcpv6. Some of these options other working group has been waiting on for over a year. /jim On Wed, 23 Jan 2002, Bernie Volz (EUD) wrote: > Jim: > > I am *NOT* saying these options aren't important. It is just to clearly specify which options should appear in which document. I think we should work very hard to get the additional drafts done for these options. It is just that we should say that if an option is strictly related to the operation of the DHCP protocol, it should be in the base specification. It is related only to data that configures a client, it can be documented in a separate specification. > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Tuesday, January 22, 2002 11:41 PM > To: Bernie Volz (EUD) > Cc: Ralph Droms; dhcwg@ietf.org > Subject: RE: [dhcwg] Options in base doc for DHCPv6 > > > Bernie, > > Again DNS options are needed NOW for IPv6 deployment. Specifically for > IPv6 DNS Stateless discovery. > > That which is needed for IPv6 deployment is as important to any option we > have in the spec. > > Implementors like VJ and others need these now the reason is we are so > late with DHC6 for the market we do not have the luxury to not include > basic options which which are required by the IPv6 market early adopters. > > So I would argue this should affect our thinking on this discussion. > Right now boot server for diskess nodes is less important to the market > (our customer here) than configured tunnel option. > > /jim > > > On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote: > > > Ralph: > > > > I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. > > > > I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. > > > > For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. > > > > - Bernie > > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Tuesday, January 22, 2002 2:56 PM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Options in base doc for DHCPv6 > > > > > > We've recently experienced a proliferation of proposed and defined options > > for DHCPv6. Initially, the WG agreed to publish all options that were > > defined at the time the base spec was completed in the same doc. I'm > > having second thoughts about that decision. Here's what I'm thinking: > > > > * The new options are adding more weight to > > an already hefty document > > * Keeping all the options in one doc make > > updating any one option more complicated > > * Reviewing all of these options will slow > > down the acceptance process > > > > I propose that we put a moratorium on adding any new options to > > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > > "essential" is open to discussion; here's a first pass at a list of the > > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > > > * DHCP unique identifier option > > * Identity association option > > * IA Address option > > * Requested Temporary Addresses (RTA) Option > > * Option request option > > * Preference option > > * Elapsed Time > > * Client message option > > * Server message option > > * Authentication option > > * Server unicast option > > * Domain Search Option > > * Domain Name Server Option > > * Status Code Option > > > > - Ralph > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:49:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20315; Wed, 23 Jan 2002 13:49:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11127; Wed, 23 Jan 2002 13:48:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11103 for ; Wed, 23 Jan 2002 13:48:05 -0500 (EST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20273 for ; Wed, 23 Jan 2002 13:48:02 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel9.hp.com (Postfix) with ESMTP id 0D444E00124; Wed, 23 Jan 2002 13:47:32 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id AAA04289; Thu, 24 Jan 2002 00:21:52 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231851.AAA04289@dce.india.hp.com> Subject: Re: [dhcwg] Options in base doc for DHCPv6 To: rdroms@cisco.com Date: Thu, 24 Jan 2002 00:21:51 +0530 (IST) Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020123115503.00b984b0@funnel.cisco.com> from Ralph Droms at Jan "23," 2002 "11:57:09" am X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I dont agree. DNS is a very critical application. Most of the applications work with names rather than IP addresses. The host badly needs this for resolving names. Moreover, this option is occurring in last 3-4 versions of the draft. Still now, we didn't get any mails saying that the format is wrong. It means that, it is reviewed and accepted by the WG. Why do you want to move out a more stabilised option which is very much required? > I propose we move Domain Search Option and Domain Name Server Option out of > the base DHCPv6 spec, as well... > > - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:54:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20481; Wed, 23 Jan 2002 13:54:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11361; Wed, 23 Jan 2002 13:53:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11334 for ; Wed, 23 Jan 2002 13:53:22 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20467 for ; Wed, 23 Jan 2002 13:53:19 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB02088; Wed, 23 Jan 2002 13:53:11 -0500 Date: Wed, 23 Jan 2002 13:53:11 -0500 (EST) From: Jim Bound Reply-To: Jim Bound To: Martin Stiemerling Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <5890000.1011774024@elgar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Martin, Exactly why we need these options now. IPv6 is being deployed. It will take at least 3 IETF meetings to get a specific options draft after dhc6. We cannot wait. Also these options will not hold up the processs. They are pretty basic. /jim On Wed, 23 Jan 2002, Martin Stiemerling wrote: > I totally agree with this. Escpecially the point of slowing down the > acceptance process is worth to mention. A lot of IPv6 networks are in the > deployment process or will be deployed in the near future and DHCPv6 is > needed for this deployment, i.e. there should be a standard. > > Martin > > > > --On Dienstag, Januar 22, 2002 14:55:41 -0500 Ralph Droms > wrote: > > > We've recently experienced a proliferation of proposed and defined > > options for DHCPv6. Initially, the WG agreed to publish all options that > > were defined at the time the base spec was completed in the same doc. > > I'm having second thoughts about that decision. Here's what I'm thinking: > > > > * The new options are adding more weight to > > an already hefty document > > * Keeping all the options in one doc make > > updating any one option more complicated > > * Reviewing all of these options will slow > > down the acceptance process > > > > I propose that we put a moratorium on adding any new options to > > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > > "essential" is open to discussion; here's a first pass at a list of the > > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > > > * DHCP unique identifier option > > * Identity association option > > * IA Address option > > * Requested Temporary Addresses (RTA) Option > > * Option request option > > * Preference option > > * Elapsed Time > > * Client message option > > * Server message option > > * Authentication option > > * Server unicast option > > * Domain Search Option > > * Domain Name Server Option > > * Status Code Option > > > > - Ralph > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Martin.Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 13:58:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20600; Wed, 23 Jan 2002 13:58:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11693; Wed, 23 Jan 2002 13:57:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11669 for ; Wed, 23 Jan 2002 13:57:28 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20587 for ; Wed, 23 Jan 2002 13:57:26 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-241.cisco.com [10.82.224.241]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA10281; Wed, 23 Jan 2002 10:56:54 -0800 (PST) Message-Id: <4.3.2.7.2.20020123135018.019cf5c8@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 13:55:42 -0500 To: Ralph Droms From: John Schnizlein Subject: Re: [dhcwg] Options in base doc for DHCPv6 Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020123115503.00b984b0@funnel.cisco.com> References: <5890000.1011774024@elgar> <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 11:57 AM 1/23/2002, Ralph Droms wrote: >I propose we move Domain Search Option and >Domain Name Server Option out of the base DHCPv6 spec, as well... I think you just threw the baby out with the bath water. How is the host supposed to find a Domain Name Server? Without DNS lookups, how can the host find SVR records? The security issues with Domain Search justify putting it off, but we should keep DNS in the base spec. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 15:21:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23789; Wed, 23 Jan 2002 15:21:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15482; Wed, 23 Jan 2002 15:19:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15457 for ; Wed, 23 Jan 2002 15:18:59 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23637 for ; Wed, 23 Jan 2002 15:18:56 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp45.summer.secret-wg.org [193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NKEoa24962; Wed, 23 Jan 2002 12:14:50 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NKHq001858; Wed, 23 Jan 2002 21:17:52 +0100 (CET) Date: Wed, 23 Jan 2002 21:17:51 +0100 Subject: Re: [dhcwg] Comments on 22 rev of the draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: Ted.Lemon@nominum.com, dhcwg@ietf.org To: Vijay Bhaskar A K From: Ted Lemon In-Reply-To: <200201231840.AAA04214@dce.india.hp.com> Message-Id: <47103B09-103E-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > Router is advertising 3ffe::/64 > prefix and a host has generated an address of prefix 3ffe::/64 using > router advertisements. Now, the host needs some more addresses of > prefix 3ffe::/64. Why would the client want to do this? What mechanism would cause the client to do this? > It chooses to use stateful autoconf (dhcpv6). The > server sends advertise saying that, it can allocate addresses in > 3ffe::/64 and 5ffe::/64. Unless I misunderstand the DHCPv6 draft, this is _not_ how it works. The server allocates addresses for the client. The client can ask for temporary addresses, but otherwise it simply takes what the server offers. There's no either-or proposition here - the server offers what it offers, and the client takes all of it. There is no reason why the client should need to pick and choose - if the server says it will give the client addresses on both these networks in the DHCP Advertise message, then when the client sends a DHCP Request message, the DHCP server will in fact give the client addresses on both these networks. AFAIK it is not intended in the draft that the client either need to nor be able to pick and choose among addresses within an IA. > Obviosuly, the client using the stateless autoconf, knows the prefixes > in the link, (by router advertisements). From the Advertise messages of > the various servers, it knows about the prefixes in the link. This is not only not true, but it doesn't answer the question I asked. Unless I am dreadfully mistaken, there is no requirement that there be a router on a link in order for IPv6 networking to function. And the question was not "how does the client know what prefixes are available on the link," but rather, "on what basis would the client want to choose between such prefixes?" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 15:21:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23784; Wed, 23 Jan 2002 15:21:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15536; Wed, 23 Jan 2002 15:19:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15509 for ; Wed, 23 Jan 2002 15:19:56 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23679 for ; Wed, 23 Jan 2002 15:19:53 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp45.summer.secret-wg.org [193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NKFla24967; Wed, 23 Jan 2002 12:15:47 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NKIn001862; Wed, 23 Jan 2002 21:18:49 +0100 (CET) Date: Wed, 23 Jan 2002 21:18:48 +0100 Subject: Re: [dhcwg] Options in base doc for DHCPv6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: rdroms@cisco.com, dhcwg@ietf.org To: Vijay Bhaskar A K From: Ted Lemon In-Reply-To: <200201231851.AAA04289@dce.india.hp.com> Message-Id: <69035262-103E-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > I dont agree. DNS is a very critical application. Most of the > applications work with names rather than IP addresses. The host badly > needs this for resolving names. Moreover, this option is occurring in > last 3-4 versions of the draft. Still now, we didn't get any mails > saying that the format is wrong. It means that, it is reviewed and > accepted by the WG. Why do you want to move out a more stabilised > option which is very much required? > I have to agree here. I don't see any reason to remove options about which there is no controversy from the DHCPv6 draft. I think it's fine to say "no more," but not to start taking them all out. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 15:34:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24253; Wed, 23 Jan 2002 15:34:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16410; Wed, 23 Jan 2002 15:33:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16383 for ; Wed, 23 Jan 2002 15:33:15 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24234 for ; Wed, 23 Jan 2002 15:33:12 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp45.summer.secret-wg.org [193.0.5.45]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NKT6a24999; Wed, 23 Jan 2002 12:29:06 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NKW8001878; Wed, 23 Jan 2002 21:32:08 +0100 (CET) Date: Wed, 23 Jan 2002 21:32:07 +0100 Subject: Re: [dhcwg] Comments on 22 rev of the draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Vijay Bhaskar A K From: Ted Lemon In-Reply-To: <200201231848.AAA04251@dce.india.hp.com> Message-Id: <45320437-1040-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > But, tell me as an implementator of DHCPv4, don't you feel it is worth > adding the text for this, atleast as an implementator notes? No! I don't think there's any reason to tell people to implement it this way. Maybe I'm interpreting what you're saying too strictly - I would not object to language like this: The DHCP server should (lowercase!) allocate new leases in such a way that it does not offer the same IP address to two clients in two successive DHCP Advertise messages if one client fails to respond to a DHCP Advertise before the second client sends a DHCP Solicit message. (or something to that effect) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 17:09:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27641; Wed, 23 Jan 2002 17:09:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20460; Wed, 23 Jan 2002 17:07:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23397 for ; Mon, 21 Jan 2002 14:02:42 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20048 for ; Mon, 21 Jan 2002 14:02:39 -0500 (EST) Received: from mail01g.rapidsite.net (mail01g.rapidsite.net [207.158.192.232]) by mail.bucknell.edu (8.11.6/8.11.6) with SMTP id g0LJ2fC19768 for ; Mon, 21 Jan 2002 14:02:41 -0500 (EST) Received: from www.ontash.com (209.238.22.8) by mail01g.rapidsite.net (RS ver 1.0.62s) with SMTP id 022099 for ; Mon, 21 Jan 2002 14:01:43 -0500 (EST) Message-ID: <000a01c1a2ae$522bdca0$7300a8c0@hq.ontash.com> Reply-To: "Bimal Shah" From: "Bimal Shah" To: Date: Mon, 21 Jan 2002 14:03:32 -0500 Organization: Ontash & Ermac MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1A284.68FEDB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Loop-Detect: 1 Subject: [dhcwg] dhcp question Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1A284.68FEDB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi: well i had one question. if i install DHCP server in my existing network = which is already assinged with diff. IP addresses then when i add more = device into network then what happens.=20 will the DHCP server assing the IP other then which are already in the = network. Will all the previous network work as usual. Thanks bimal ------=_NextPart_000_0007_01C1A284.68FEDB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi:
 
well i had one question. if i install = DHCP server=20 in my existing network which is already assinged with diff. IP addresses = then=20 when i add more device into network then what happens.
 
will the DHCP server assing the IP = other then which=20 are already in the network. Will all the previous network work as=20 usual.
 
Thanks
bimal
------=_NextPart_000_0007_01C1A284.68FEDB00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 17:54:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28635; Wed, 23 Jan 2002 17:54:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21806; Wed, 23 Jan 2002 17:51:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21782 for ; Wed, 23 Jan 2002 17:51:45 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28540 for ; Wed, 23 Jan 2002 17:51:42 -0500 (EST) Received: from BarrH63p601 ([64.170.119.193]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQE004R8Y68PK@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Wed, 23 Jan 2002 14:51:44 -0800 (PST) Date: Wed, 23 Jan 2002 14:50:49 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Assigning DHCPv6 option codes In-reply-to: <4.3.2.7.2.20020123123638.03826d80@funnel.cisco.com> To: Dhcwg Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ralph Droms > Sent: Wednesday, January 23, 2002 09:43 > > There's a little more to it than just the scarcity of option codes in > DHCPv4. Just before we instituted the new policy of assigning an option > code after acceptance to PS, there were several (10-15 or so) that were > proposed, had option codes assigned, and then were never followed up > on. Those option codes are now in limbo. > > Even though we have plenty of options code in DHCPv6, I don't > think it's a good idea to have option codes in an uncertain state - > assigned to options that never went to PS. Perhaps we need some sort > of sunsetting to establish a process for marking option codes as > "unused - do not reassign"... > ...you may recall that I proposed exactly that -- the sunsetting of option codes -- at least twice in working group meetings, but Thomas Narten argued convincingly that the IETF has never been very good at enforcing adherence to updated RFCs, and may never be able to do anything but move an RFC to Historic status, which doesn't provide any practical, timely relief for the option exhaustion problem. I'd love for most options to be subject either to a sunset clause, but I don't know how effective it would be -- certainly one side effect would be to keep the DHC working group in existence for a long, long time. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 18:01:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28766; Wed, 23 Jan 2002 18:01:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22114; Wed, 23 Jan 2002 18:00:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22080 for ; Wed, 23 Jan 2002 18:00:15 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28740 for ; Wed, 23 Jan 2002 18:00:12 -0500 (EST) Received: from BarrH63p601 ([64.170.119.193]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQE00LLPYKEVM@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Wed, 23 Jan 2002 15:00:14 -0800 (PST) Date: Wed, 23 Jan 2002 14:59:18 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Assigning DHCPv6 option codes In-reply-to: <05B2A5F1-0FFE-11D6-AF3C-00039317663C@nominum.com> To: Dhcwg Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ted Lemon > Sent: Wednesday, January 23, 2002 04:38 > > I am unaware of a single example where site-specific options have > ever been used. > ... many "thin clients" such as Wyse used those option numbers for their configuration. Of course, that is really "vendor-specific" and not "site-specific" but it still is the same number range (128-254). > This is why I think it's better not to put language about > reserved portions of the option space in the base draft - I think > we need to figure out what we want to do carefully. Is it really > site-specific that we want? > What about vendor-specific? What about user-defined? If you > want to reserve any space in the draft, I would just call the > reserved space "experimental" rather than being specific about who > can use it. Reserving 4096 codes is probably plenty, though, as you > say - I don't think we need 32k. > ...and I agree that "experimental" or "not defined by RFC" or some similar title is appropriate, as well as a reasonably small space such as 4096 codes. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 18:17:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29026; Wed, 23 Jan 2002 18:17:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22619; Wed, 23 Jan 2002 18:14:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22596 for ; Wed, 23 Jan 2002 18:14:38 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29006 for ; Wed, 23 Jan 2002 18:14:35 -0500 (EST) Received: from BarrH63p601 ([64.170.119.193]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQE004BMZ8D1S@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Wed, 23 Jan 2002 15:14:38 -0800 (PST) Date: Wed, 23 Jan 2002 15:13:42 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Status codes for Information-Request In-reply-to: <4.3.2.7.2.20020123113115.037238a0@funnel.cisco.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ralph Droms > Sent: Wednesday, January 23, 2002 08:33 > > Open issue from WG last call: > > * What status codes may a server send in response to an > Information-Request message? > > I propose: Success, UnspecFail, AuthFailed, PoorlyFormed, OptionUnavail > ...why be "cheap" with names? I'd prefer they be spelled out: Success, UnpecifiedFailure, AuthorizationFailed, PoorlyFormed, OptionUnavailable, and DUIDneeded. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 18:31:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29277; Wed, 23 Jan 2002 18:31:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23214; Wed, 23 Jan 2002 18:30:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23182 for ; Wed, 23 Jan 2002 18:30:44 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29247 for ; Wed, 23 Jan 2002 18:30:41 -0500 (EST) Received: from BarrH63p601 ([64.170.119.193]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQE000YZZZ7GI@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Wed, 23 Jan 2002 15:30:44 -0800 (PST) Date: Wed, 23 Jan 2002 15:29:48 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Options in base doc for DHCPv6 In-reply-to: <69035262-103E-11D6-AF3C-00039317663C@nominum.com> To: Dhcwg Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ted Lemon > Sent: Wednesday, January 23, 2002 12:19 > > I don't see any reason to remove options about which there is no > controversy from the DHCPv6 draft. I think it's fine to > say "no more," but not to start taking them all out. > ...exactly. Is it possible to construct a simple test by which to judge an option as appropriate for inclusion in the base document? For example: (1) is it required for implementation or deployment of a crucial service (for example, DNS or SLP) (2) is it essential to implement mandatory or highly desirable functionality (such as authentication or security)? (3) is it necessary to support transition from IPv4 to IPv6? (4) is it currently widely deployed with DHCPv4? (5) has the option been stably defined for DHCPv6 for at least several draft revisions? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 18:39:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29389; Wed, 23 Jan 2002 18:39:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23444; Wed, 23 Jan 2002 18:37:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23425 for ; Wed, 23 Jan 2002 18:37:21 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29376 for ; Wed, 23 Jan 2002 18:37:17 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-86.cisco.com [161.44.149.86]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA24039 for ; Wed, 23 Jan 2002 18:36:50 -0500 (EST) Message-Id: <4.3.2.7.2.20020123183552.036d9e30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 18:37:15 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] Status codes for Information-Request In-Reply-To: References: <4.3.2.7.2.20020123113115.037238a0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Barr, I don't disagree with your choice of names - I was simply re-using existing status codes from draft -23... - Ralph At 03:13 PM 1/23/2002 -0800, Richard Barr Hibbs wrote: > > -----Original Message----- > > From: Ralph Droms > > Sent: Wednesday, January 23, 2002 08:33 > > > > Open issue from WG last call: > > > > * What status codes may a server send in response to an > > Information-Request message? > > > > I propose: Success, UnspecFail, AuthFailed, PoorlyFormed, OptionUnavail > > >...why be "cheap" with names? I'd prefer they be spelled out: Success, >UnpecifiedFailure, AuthorizationFailed, PoorlyFormed, OptionUnavailable, and >DUIDneeded. > >--Barr > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 23 18:56:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29759; Wed, 23 Jan 2002 18:56:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23762; Wed, 23 Jan 2002 18:55:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23736 for ; Wed, 23 Jan 2002 18:55:33 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29744 for ; Wed, 23 Jan 2002 18:55:29 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta4/8.12.2.Beta4) id g0NNtWFh026414 for dhcwg@ietf.org env-from ; Wed, 23 Jan 2002 16:55:32 -0700 (MST) Date: Wed, 23 Jan 2002 16:55:32 -0700 (MST) From: Vernon Schryver Message-Id: <200201232355.g0NNtWFh026414@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > From: Richard Barr Hibbs > > I am unaware of a single example where site-specific options have > > ever been used. > > > ... many "thin clients" such as Wyse used those option numbers for their > configuration. Of course, that is really "vendor-specific" and not > "site-specific" but it still is the same number range (128-254). > ... I thought RFC 2132 clearly separated the site-specific range [128,254] from the vendor-specific range defined in section 8.4. Where is the overlap? Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 24 00:26:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06787; Thu, 24 Jan 2002 00:26:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02669; Thu, 24 Jan 2002 00:24:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02638 for ; Thu, 24 Jan 2002 00:24:16 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06753 for ; Thu, 24 Jan 2002 00:24:14 -0500 (EST) Received: from BarrH63p601 ([64.170.119.193]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQF00IM6GCFUL@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Wed, 23 Jan 2002 21:24:15 -0800 (PST) Date: Wed, 23 Jan 2002 21:23:18 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Assigning DHCPv6 option codes In-reply-to: <200201232355.g0NNtWFh026414@calcite.rhyolite.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Vernon Schryver > Sent: Wednesday, January 23, 2002 15:56 > > I thought RFC 2132 clearly separated the site-specific range > [128,254] from the vendor-specific range defined in section 8.4. > Where is the overlap? > ...hmmmm... the imprecision of words..... yes, vendor-specific <> is encoded as specified in section 8.4 into the value field of a single DHCP <