From dhcwg-bounces@ietf.org Mon May 02 09:27:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSaxB-0001uM-0x; Mon, 02 May 2005 09:27:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSax2-0001Zk-NK for dhcwg@megatron.ietf.org; Mon, 02 May 2005 09:27:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16204 for ; Mon, 2 May 2005 09:27:07 -0400 (EDT) Received: from mail-sin1.microsoft.com ([207.46.50.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSbAj-0003mK-5h for dhcwg@ietf.org; Mon, 02 May 2005 09:41:17 -0400 Received: from APS-MSG-01.southpacific.corp.microsoft.com ([157.60.218.45]) by mail-sin1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 May 2005 22:26:56 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 May 2005 21:26:54 +0800 Message-ID: Thread-Topic: RFC 2132: Minimum DHCP message size question thread-index: AcVPGpuC4SKwB55NSkeC9eVS93VGKQ== From: "Santosh Chandwani" To: X-OriginalArrivalTime: 02 May 2005 13:26:56.0080 (UTC) FILETIME=[9C59C500:01C54F1A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [dhcwg] RFC 2132: Minimum DHCP message size question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1122448362==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1122448362== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54F1A.9CD4E1AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C54F1A.9CD4E1AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 2132, Section 9.10 describes the Maximum DHCP Message Size option and states that the minimum size that a DHCP service must accept is 576 bytes. =20 Microsoft is trying to address an issue with the DHCP client, where the DHCP service running on some smaller routers do not accept DHCP messages of size larger than 576 bytes. This becomes an issue in cases where the client tries to send a vendor-specific or another option of large size, which causes the message size to grow beyond 576 bytes. To properly address the issue, we want to verify that the constraint applies only to DHCP servers. Although it's highly unlikely, we want to ensure that there are no DHCP Relay Agents which impose a restriction on the size of the DHCP message they will forward. Insights you can share on the subject will be appreciated. =20 Thanks, Santosh =20 ------_=_NextPart_001_01C54F1A.9CD4E1AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 2132, Section 9.10 describes the Maximum DHCP = Message Size option and states that the minimum size that a DHCP service must = accept is 576 bytes.

 

Microsoft is trying to address an issue with the DHCP client, where the DHCP service running on some smaller routers do not = accept DHCP messages of size larger than 576 bytes. This becomes an issue in cases = where the client tries to send a vendor-specific or another option of large size, = which causes the message size to grow beyond 576 bytes. To properly address = the issue, we want to verify that the constraint applies only to DHCP = servers. Although it’s highly unlikely, we want to ensure that there are no DHCP = Relay Agents which impose a restriction on the size of the DHCP message they = will forward. Insights you can share on the subject will be = appreciated.

 

Thanks,

Santosh

 

------_=_NextPart_001_01C54F1A.9CD4E1AC-- --===============1122448362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1122448362==-- From dhcwg-bounces@ietf.org Mon May 02 11:14:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DScdD-00019G-Ru; Mon, 02 May 2005 11:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DScdB-00018s-GF for dhcwg@megatron.ietf.org; Mon, 02 May 2005 11:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25000 for ; Mon, 2 May 2005 11:14:43 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DScqr-0005jX-Qg for dhcwg@ietf.org; Mon, 02 May 2005 11:28:55 -0400 Received: from [10.175.247.253] (m210e36d0.tmodns.net [208.54.14.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id A615B56856; Mon, 2 May 2005 08:14:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <16D47345-444E-46F6-9203-07B767B534D2@nominum.com> Content-Transfer-Encoding: quoted-printable From: Ted Lemon Subject: Re: [dhcwg] RFC 2132: Minimum DHCP message size question Date: Mon, 2 May 2005 10:10:20 -0500 To: Santosh Chandwani X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 2, 2005, at 8:26 AM, Santosh Chandwani wrote: > > Microsoft is trying to address an issue with the DHCP client, where =20= > the DHCP service running on some smaller routers do not accept DHCP =20= > messages of size larger than 576 bytes. This becomes an issue in =20 > cases where the client tries to send a vendor-specific or another =20 > option of large size, which causes the message size to grow beyond =20 > 576 bytes. To properly address the issue, we want to verify that =20 > the constraint applies only to DHCP servers. Although it=92s highly =20= > unlikely, we want to ensure that there are no DHCP Relay Agents =20 > which impose a restriction on the size of the DHCP message they =20 > will forward. Insights you can share on the subject will be =20 > appreciated. > > BOOTP relay agents follow the BOOTP RFC, not the DHCP RFC, and the =20 bootp RFC doesn't require them to pass messages larger than 576 =20 bytes. So it's quite possible, unfortunately, that there is some =20 relay agent out there that doesn't support large DHCP packets. And =20 unfortunately, that relay agent would not be out of spec. I don't =20 know of any place in RFC2131 or RFC2132 where any requirement is =20 placed on BOOTP relay agents. Now, is a lame relay agent like this broken? I would say it is. =20 It should certainly never be advertised as supporting DHCP. But is =20 it out of spec? Unfortunately no. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 02 23:29:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSo6N-0000nU-4e; Mon, 02 May 2005 23:29:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSo6L-0000nH-Lt; Mon, 02 May 2005 23:29:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19685; Mon, 2 May 2005 23:29:35 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSoK6-0001ui-4P; Mon, 02 May 2005 23:43:53 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IFW001VF9OYJC@mailout2.samsung.com>; Tue, 03 May 2005 12:29:23 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IFW002MR9OYVM@mmp1.samsung.com>; Tue, 03 May 2005 12:29:22 +0900 (KST) Date: Tue, 03 May 2005 12:29:10 +0900 From: "Soohong Daniel Park@SAMSUNG.COM" In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= , "'Pekka Savola'" Message-id: <000701c54f90$4533e140$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, 'IPv6 WG' Subject: [dhcwg] [Resolving Issues]IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi all I've tried to note down several considerable points. Let me know your view on them if I am missing anything. If acceptable, I will make a revision once more. ============================================ + means Concern - means Considerable mentions from ML $ means trial efforts on resolving them [Issue 1] "Client operation which is set to M-Policy 1 along with 3736 DHCPv6 server" + if a full DHCPv6 client is initiated and server is only 3736, the client get back the Information Configuration Behaviour ? or sending the Solicit to server forever ? - Just indicating that it's host/network admin misconfiguration - Fall-back behaviour to Information Configuration Behaviour (see Issue 2) - Updating original DHCPv6 specifications (3315, 3736) $ Trial: just saying this issue as an admin misconfiguration including Trial text of Issue 2. [Issue 2] "Parallel operation of HCB and ICB with DHCPv6 specification" RFC3315 does not preclude a client from initiating an Information-request /Reply message exchange in parallel with or subsequent to a Solicit /Advertise/Request/Reply message exchange + Breaking the sense of RFC2462 (Section 5.5.3) - Remaining it as a general issue and simple mention in this document $ Trial: if a client does not receive any response from DHCPv6 server while performing Host Configuration Behaviour, the client then begins Information Configuration Behaviour in parallel with Host Configuration Behaviour. It causes a considerable case as non-addresses configuration since Information Configuration Behaviour does not include addresses information. The authors remain this issue to be resolved in the related working group (probably DHC WG). [Issue 3] "Inconsistent M and O flags of RA" + Inconsistent RA is a in-scope problem of this document ? - More describing of why M/O transitions are a bigger problem than other inconsistent information $Trial: In the end, it is administrator's responsibility to ensure the consistency among Router Advertisement parameters from multiple routers in the same single link as described in Section 5.6 of [RFC2462]. The authors thus remain "Handling of M and O flags from multiple routers" out of scope of this document. [Issue 4] "Default policy on M/O flags" HCB using RFC3315 - M-Policy 2, otherwise M-Policy 3 (HCB is not implemented) ICB using RFC3736 - O-Policy 1 or 2 + Is it fully acceptable ? $Trial: If not acceptable, please make more comments. ! [Editorial] + In the last sentence of Section 12 - s/is different form/is different from/ $Trial: done + SEND is now published as an RFC (RFC3971) $Trial: done + if we need an update version of this document (I believe we do), - we'll need to use the new IPR boilerplate (e.g., with version 1.29 of xml2rfc) $Trial: will be done by next version ============================================ Thanks. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 05 10:44:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThaR-0000gN-4v; Thu, 05 May 2005 10:44:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThaQ-0000gF-FT for dhcwg@megatron.ietf.org; Thu, 05 May 2005 10:44:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04858 for ; Thu, 5 May 2005 10:44:19 -0400 (EDT) Received: from mail-sin2.microsoft.com ([207.46.50.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DThoi-0005nJ-CG for dhcwg@ietf.org; Thu, 05 May 2005 10:59:10 -0400 Received: from APS-MSG-02.southpacific.corp.microsoft.com ([157.60.218.52]) by mail-sin2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 22:44:02 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 May 2005 22:44:21 +0800 Message-ID: <91AC940D24F18041A3A68895289CE1EE021A9581@APS-MSG-02.southpacific.corp.microsoft.com> Thread-Topic: Multiple IP addresses for DHCPv6 clients Thread-Index: AcVRgOw7KzADIHFOR1OfKQKlUsN0+w== From: "Achint Setia" To: X-OriginalArrivalTime: 05 May 2005 14:44:02.0613 (UTC) FILETIME=[E137EE50:01C55180] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Subject: [dhcwg] Multiple IP addresses for DHCPv6 clients X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0627528074==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0627528074== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55180.E0FCB4CF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55180.E0FCB4CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The DHCPv6 RFC 3315 mentions that the client can send multiple IAs in a packet. I have the following queries regarding the same:- =20 1. If the client wants to request multiple IP addresses from the server, should it send as many IA_Addr in a single IA_NA (i.e under the same IAID) in the SOLICIT message or send multiple IA_NAs each with a single IA Address field. I am asking this because the server identifies a client binding by the triplet which means in case of the first option, there have to be multiple addresses in the same binding. =20 2. Suppose after getting an address, the client wants to get another address. Should it send another SOLICIT with a new IAID or can it use the previous IAID to get the new address (assuming multiple addresses per binding) =20 3. The RFC says in section 18.1.3 (Creation and Transmission of Renew Messages) "The server may also add new addresses to the IA" What are the possible scenarios in which the server can itself chose to send multiple IP addresses to the client without going through the normal 4 way=20 Handshake. Can we use this as a solution to the issue (2) I mentioned? =20 =20 I'll appreciate your help in this regard. =20 Thanks, Achint Setia, Microsoft. =20 ------_=_NextPart_001_01C55180.E0FCB4CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The DHCPv6 RFC 3315 mentions that the client can send multiple IAs in a packet. I have the following queries regarding the = same:-

 

  1. If the client wants to request multiple IP = addresses from the server, should it send as many IA_Addr in a single IA_NA (i.e = under the same IAID) in the SOLICIT message or send multiple IA_NAs each = with a single IA Address field. I am asking this because the server identifies a = client binding by the triplet <DUID,  IA_Type, IAID> which = means in case of the first option, there have to be multiple addresses in = the same binding.

 

  1. Suppose after getting an address, the client = wants to get another address. Should it send another SOLICIT with a new IAID = or can it use the previous IAID to get the new address (assuming multiple addresses per binding)

 

  1. The RFC says in section 18.1.3 (Creation and Transmission of Renew Messages) “The server may also add new addresses to the = IA”

What are the possible = scenarios in which the server can itself chose to send multiple IP addresses to the = client without going through the normal 4 way

Handshake. Can we use this = as a solution to the issue (2) I mentioned?

 

 

I’ll appreciate your help in this = regard.

 

Thanks,

Achint Setia,

Microsoft.

 

------_=_NextPart_001_01C55180.E0FCB4CF-- --===============0627528074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0627528074==-- From dhcwg-bounces@ietf.org Thu May 05 11:54:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTifo-0005oo-Mn; Thu, 05 May 2005 11:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTifn-0005od-GQ for dhcwg@megatron.ietf.org; Thu, 05 May 2005 11:53:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12574 for ; Thu, 5 May 2005 11:53:56 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTiu6-0000uS-Fh for dhcwg@ietf.org; Thu, 05 May 2005 12:08:47 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 05 May 2005 08:53:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j45FrcrG006544; Thu, 5 May 2005 08:53:46 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 11:53:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Multiple IP addresses for DHCPv6 clients Date: Thu, 5 May 2005 11:53:43 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2122D1E6@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Multiple IP addresses for DHCPv6 clients Thread-Index: AcVRgOw7KzADIHFOR1OfKQKlUsN0+wABVx0w From: "Bernie Volz \(volz\)" To: "Achint Setia" , X-OriginalArrivalTime: 05 May 2005 15:53:43.0239 (UTC) FILETIME=[9D10D570:01C5518A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi: =20 Comments inline. - Bernie ________________________________ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Achint Setia Sent: Thursday, May 05, 2005 10:44 AM To: dhcwg@ietf.org Subject: [dhcwg] Multiple IP addresses for DHCPv6 clients =09 =09 Hi, =20 The DHCPv6 RFC 3315 mentions that the client can send multiple IAs in a packet. I have the following queries regarding the same:- =20 1. If the client wants to request multiple IP addresses from the server, should it send as many IA_Addr in a single IA_NA (i.e under the same IAID) in the SOLICIT message or send multiple IA_NAs each with a single IA Address field. I am asking this because the server identifies a client binding by the triplet which means in case of the first option, there have to be multiple addresses in the same binding.=20 BV> Do not send multiple IAADDRs unless you want to explicitly request addresses. There is no reason to send *ANY* IAADDR options in a Solicit unless you want to request a specific address. If you want multiple addresses, you MUST send multiple IA_NAs. However, can you give me an example of why you would ever need to do this? 2. Suppose after getting an address, the client wants to get another address. Should it send another SOLICIT with a new IAID or can it use the previous IAID to get the new address (assuming multiple addresses per binding)=20 BV> You could simply send a REQUEST with a new IA. But, as a request is directed to a single server, this presumes that the server is the correct one. So, a SOLICIT may be the better approach. Again, under what conditions would your client need to do this? Do you have an example? Note that if a client's previous address needs to be renewed, the RENEW may either give the client the same address (with new lifetimes) or could give the client NEW addresses. 3. The RFC says in section 18.1.3 (Creation and Transmission of Renew Messages) "The server may also add new addresses to the IA"=20 What are the possible scenarios in which the server can itself chose to send multiple IP addresses to the client without going through the normal 4 way=20 Handshake. Can we use this as a solution to the issue (2) I mentioned? BV> I just mentioned a case in answer to section 2. A more concrete example is: Client obtains address with lifetimes. When it renews, the server's configuration has changed and a second prefix is available. When the server processes the Renew, it will likely send BOTH address - the original the client had (perhaps even with 0 lifetimes to tell the client do remove that address) AND the new one. This can also happen if the server has policy that, for example, doesn't allow the old address to be renewed. In this case, the client would get a new address (and perhaps also be sent the old). When processing a REPLY to a REQUEST or RENEW/REBIND, the client generally would do the following processing: For all addresses received, either add the address to the client's configuration (if new and after doing DAD) or update the lifetimes if it exists. If an address that the client had is NOT in the REPLY, the old information for that address should be retained (it probably means that the server is unwilling to renew that addresss and decided not to include it in the REPLY). =20 =20 I'll appreciate your help in this regard. =20 Thanks, Achint Setia, Microsoft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 05 12:50:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjYG-0003Uf-Jz; Thu, 05 May 2005 12:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjYE-0003UP-NM for dhcwg@megatron.ietf.org; Thu, 05 May 2005 12:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17584 for ; Thu, 5 May 2005 12:50:11 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjmZ-0003en-2P for dhcwg@ietf.org; Thu, 05 May 2005 13:05:03 -0400 Received: from [10.0.1.7] (dialup-4.244.198.208.Dial1.StLouis1.Level3.net [4.244.198.208]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 26E2D568AE; Thu, 5 May 2005 09:49:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <91AC940D24F18041A3A68895289CE1EE021A9581@APS-MSG-02.southpacific.corp.microsoft.com> References: <91AC940D24F18041A3A68895289CE1EE021A9581@APS-MSG-02.southpacific.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <847A5B4A-0302-4134-B89F-E8DBD999793C@nominum.com> Content-Transfer-Encoding: quoted-printable From: Ted Lemon Subject: Re: [dhcwg] Multiple IP addresses for DHCPv6 clients Date: Thu, 5 May 2005 11:46:11 -0500 To: Achint Setia X-Mailer: Apple Mail (2.728) X-Spam-Score: 2.9 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 5, 2005, at 9:44 AM, Achint Setia wrote: > If the client wants to request multiple IP addresses from the =20 > server, should it send as many IA_Addr in a single IA_NA (i.e under =20= > the same IAID) in the SOLICIT message or send multiple IA_NAs each =20 > with a single IA Address field. I am asking this because the server =20= > identifies a client binding by the triplet =20 > which means in case of the first option, there have to be multiple =20 > addresses in the same binding. The word "identity" in the phrase "identity association" refers to =20 the identity that the client presents to the network. When a client =20= wishes to present more than one identity to the network, it uses more =20= than one identity association. The reason for wanting more than one =20= IP address is to present more than one identity. So if a client =20 wants more than one IP address, it should present more than one IA_ID. > Suppose after getting an address, the client wants to get another =20 > address. Should it send another SOLICIT with a new IAID or can it =20 > use the previous IAID to get the new address (assuming multiple =20 > addresses per binding) It has to do an additional solicit. It's okay to renew all the IAs =20 at once, though. > The RFC says in section 18.1.3 (Creation and Transmission of Renew =20= > Messages) =93The server may also add new addresses to the IA=94 > > What are the possible scenarios in which the server can itself =20 > chose to send multiple IP addresses to the client without going =20 > through the normal 4 way > > Handshake. Can we use this as a solution to the issue (2) I mentioned? No. The reason a server would send more than one address in an IA =20 is to handle the case where a site is multi-homed. In this case, a =20 client is presenting a single identity to the network, but may need =20 more than one IP address because the site is multi-homed, so the =20 server sends the client two IP addresses for its single identity. =20 This is completely orthogonal to the question of presenting multiple =20 identities, and so you can't use this facility to acquire multiple IP =20= addresses for the client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 06 01:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTv32-0000vF-0d; Fri, 06 May 2005 01:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTv30-0000v7-Fc for dhcwg@megatron.ietf.org; Fri, 06 May 2005 01:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07254 for ; Fri, 6 May 2005 01:06:45 -0400 (EDT) Received: from mail-sin2.microsoft.com ([207.46.50.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTvHR-00064y-54 for dhcwg@ietf.org; Fri, 06 May 2005 01:21:41 -0400 Received: from APS-MSG-02.southpacific.corp.microsoft.com ([157.60.218.52]) by mail-sin2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 13:07:13 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Multiple IP addresses for DHCPv6 clients Date: Fri, 6 May 2005 13:06:33 +0800 Message-ID: <91AC940D24F18041A3A68895289CE1EE021A99D3@APS-MSG-02.southpacific.corp.microsoft.com> Thread-Topic: [dhcwg] Multiple IP addresses for DHCPv6 clients Thread-Index: AcVRgOw7KzADIHFOR1OfKQKlUsN0+wABVx0wABw735A= From: "Achint Setia" To: "Bernie Volz \(volz\)" , "Ted Lemon" X-OriginalArrivalTime: 06 May 2005 05:07:13.0181 (UTC) FILETIME=[76CD74D0:01C551F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks Bernie and Ted! Regarding the scenario where a client may request multiple IP addresses even I am not very clear whether this is required indeed, so I thought of putting that as a question for the workgroup.=20 The RFC is not very clear when it states that there can be multiple IA_Addr options in the same IA_NA. As you mentioned, each binding(or IAID) should be associated with (or request for)ONLY ONE address unless the server decides to include multiple addresses depending on some policy. Thanks for the quick response. Achint. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Thursday, May 05, 2005 9:24 PM To: Achint Setia; dhcwg@ietf.org Subject: RE: [dhcwg] Multiple IP addresses for DHCPv6 clients Hi: =20 Comments inline. - Bernie ________________________________ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Achint Setia Sent: Thursday, May 05, 2005 10:44 AM To: dhcwg@ietf.org Subject: [dhcwg] Multiple IP addresses for DHCPv6 clients =09 =09 Hi, =20 The DHCPv6 RFC 3315 mentions that the client can send multiple IAs in a packet. I have the following queries regarding the same:- =20 1. If the client wants to request multiple IP addresses from the server, should it send as many IA_Addr in a single IA_NA (i.e under the same IAID) in the SOLICIT message or send multiple IA_NAs each with a single IA Address field. I am asking this because the server identifies a client binding by the triplet which means in case of the first option, there have to be multiple addresses in the same binding.=20 BV> Do not send multiple IAADDRs unless you want to explicitly request addresses. There is no reason to send *ANY* IAADDR options in a Solicit unless you want to request a specific address. If you want multiple addresses, you MUST send multiple IA_NAs. However, can you give me an example of why you would ever need to do this? 2. Suppose after getting an address, the client wants to get another address. Should it send another SOLICIT with a new IAID or can it use the previous IAID to get the new address (assuming multiple addresses per binding)=20 BV> You could simply send a REQUEST with a new IA. But, as a request is directed to a single server, this presumes that the server is the correct one. So, a SOLICIT may be the better approach. Again, under what conditions would your client need to do this? Do you have an example? Note that if a client's previous address needs to be renewed, the RENEW may either give the client the same address (with new lifetimes) or could give the client NEW addresses. 3. The RFC says in section 18.1.3 (Creation and Transmission of Renew Messages) "The server may also add new addresses to the IA"=20 What are the possible scenarios in which the server can itself chose to send multiple IP addresses to the client without going through the normal 4 way=20 Handshake. Can we use this as a solution to the issue (2) I mentioned? BV> I just mentioned a case in answer to section 2. A more concrete example is: Client obtains address with lifetimes. When it renews, the server's configuration has changed and a second prefix is available. When the server processes the Renew, it will likely send BOTH address - the original the client had (perhaps even with 0 lifetimes to tell the client do remove that address) AND the new one. This can also happen if the server has policy that, for example, doesn't allow the old address to be renewed. In this case, the client would get a new address (and perhaps also be sent the old). When processing a REPLY to a REQUEST or RENEW/REBIND, the client generally would do the following processing: For all addresses received, either add the address to the client's configuration (if new and after doing DAD) or update the lifetimes if it exists. If an address that the client had is NOT in the REPLY, the old information for that address should be retained (it probably means that the server is unwilling to renew that addresss and decided not to include it in the REPLY). =20 =20 I'll appreciate your help in this regard. =20 Thanks, Achint Setia, Microsoft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 06 07:12:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU0kZ-0002bW-Sf; Fri, 06 May 2005 07:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU0kX-0002aF-Qg for dhcwg@megatron.ietf.org; Fri, 06 May 2005 07:12:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29976 for ; Fri, 6 May 2005 07:12:02 -0400 (EDT) Received: from cpc4-cmbg4-4-0-cust135.cmbg.cable.ntl.com ([81.108.205.135] helo=thekelleys.org.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU0z1-0003nK-0B for dhcwg@ietf.org; Fri, 06 May 2005 07:27:04 -0400 Received: from central ([192.168.0.4] helo=[127.0.0.1]) by thekelleys.org.uk with esmtp (Exim 3.35 #1 (Debian)) id 1DU0kI-0006LX-00 for ; Fri, 06 May 2005 12:11:50 +0100 Message-ID: <427B506B.1050005@thekelleys.org.uk> Date: Fri, 06 May 2005 12:09:31 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv4 - definition of maximum message size. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Does the value in "maximum message size" option (option code 56) include the IP and UDP headers? Neither RFC2131 or RFC2132 ever state this explicitly, but they are self-consistent if it's the case. RFC2132 states that the minimum legal value is 576 octets, which equals IP header + UDP header + fixed DHCP fields + the minimum 312 octet options field specified in RFC2131. I ask because I've just come across a client which advertises a maximum message size of 548. Presumably this is broken, and there's a chance that the client is also misinterpreting a "576" maximum message size option _from_ a DHCP server and could potentially try and use 28 bytes that the server cannot receive. If the wise ones here can confirm that this really is an RFC violation, I'll submit a bug report to the vendor of the client. Cheers, Simon. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 06 14:52:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7wM-0003oM-Qu; Fri, 06 May 2005 14:52:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7wL-0003oH-Ce for dhcwg@megatron.ietf.org; Fri, 06 May 2005 14:52:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22789 for ; Fri, 6 May 2005 14:52:43 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU8As-0001LT-HB for dhcwg@ietf.org; Fri, 06 May 2005 15:07:47 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id A2D4EB240B; Fri, 6 May 2005 11:52:33 -0700 (PDT) Date: Fri, 6 May 2005 11:52:33 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. Message-ID: <20050506185233.GD826@isc.org> References: <427B506B.1050005@thekelleys.org.uk> Mime-Version: 1.0 In-Reply-To: <427B506B.1050005@thekelleys.org.uk> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0619771907==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0619771907== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DrWhICOqskFTAXiy" Content-Disposition: inline --DrWhICOqskFTAXiy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 06, 2005 at 12:09:31PM +0100, Simon Kelley wrote: > Does the value in "maximum message size" option (option code 56) include= =20 > the IP and UDP headers? >=20 > Neither RFC2131 or RFC2132 ever state this explicitly, but they are=20 > self-consistent if it's the case. RFC2132 states that the minimum legal= =20 > value is 576 octets, which equals IP header + UDP header + fixed DHCP=20 > fields + the minimum 312 octet options field specified in RFC2131. To add to your confusion, ISC DHCP calculates this as: 'mms' - (ethernet + ip + udp + dhcp header sizes) Should the 'mms' be less than 576, we use 576. I suspect our inclusion of the ethernet header size in this calculation is incorrect, since as you mention it doesn't add up if you use a 312 byte options field. > I ask because I've just come across a client which advertises a maximum= =20 > message size of 548. Presumably this is broken, and there's a chance=20 > that the client is also misinterpreting a "576" maximum message size=20 > option _from_ a DHCP server and could potentially try and use 28 bytes= =20 > that the server cannot receive. As I mentioned above, I believe our DHCP server would simply not observe this mms, and pretend as though it was not supplied. > If the wise ones here can confirm that this really is an RFC violation,= =20 > I'll submit a bug report to the vendor of the client. I have no such wisdom. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --DrWhICOqskFTAXiy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCe7zxcXeLeWu2vmoRAp1kAJ9txd0j5hof1uW5H/difYjzGDkEOgCgmqGG kfbdAXj8xXLtXHVgAnfDClQ= =NZ1K -----END PGP SIGNATURE----- --DrWhICOqskFTAXiy-- --===============0619771907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0619771907==-- From dhcwg-bounces@ietf.org Fri May 06 15:06:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU89r-0006QH-Ed; Fri, 06 May 2005 15:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU89p-0006QC-HW for dhcwg@megatron.ietf.org; Fri, 06 May 2005 15:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24422 for ; Fri, 6 May 2005 15:06:39 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU8ON-000285-M6 for dhcwg@ietf.org; Fri, 06 May 2005 15:21:44 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 May 2005 15:06:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j46J5onu011715; Fri, 6 May 2005 15:06:29 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 15:06:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv4 - definition of maximum message size. Date: Fri, 6 May 2005 15:06:26 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2122D41B@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCPv4 - definition of maximum message size. Thread-Index: AcVSbRnzmjYg8vDOR2OClFlcRl277wAARDRQ From: "Bernie Volz \(volz\)" To: "David W. Hankins" , "Simon Kelley" X-OriginalArrivalTime: 06 May 2005 19:06:27.0052 (UTC) FILETIME=[B40C6AC0:01C5526E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has expired. See text below. The key part is: o Clients SHOULD communicate their link-layer frame size to the DHCP server via the DHCP MTU option.=20 So, this is *LINK-LAYER* frame size. I believe this 576 size comes from RFC 791: Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams. The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols. So, it should be treated as the "IP + UDP + DHCP" packet size. --- 2.19. Size of a BOOTP/DHCP frame=20 The description in RFC 2131 relating to the size constraints of DHCP=20 packets (Page 10, first paragraph after Table 1, section 2) is=20 inadequate.=20 2.19.1. Minimum size.=20 RFC 951 states that a minimum BOOTP frame is 300 octets in length. =20 Some BOOTP relay agents have been known to drop frames of less than=20 300 octets. RFC 951 is explicit on this point, but RFC 2131 just=20 refers to RFC 951. Since DHCP is intended to be backward compatible=20 with BOOTP, the protocol should continue to observe this lower bound.=20 RECOMMENDATIONS:=20 o Text should be added stating explicitly that the minimum size of a DHCP frame is 300 octets.=20 2.19.2. Maximum Size, MTU, and Message Size option=20 It has been thought necessary to avoid fragmentation of the IP=20 packets in DHCP/BOOTP due to concerns that some clients would be unable to reassemble fragments before the IP stack is properly=20 configured. RFC 951 states "For simplicity it is assumed that the=20 BOOTP packet is never fragmented". Regardless of theoretical=20 limitations in IP stack implementations, it is certain that there are =20 several DHCP/BOOTP implementations, at both ends of the protocol,=20 which will not reassemble.=20 Various comments in the WORKING GROUP imply that fragmentation could=20 be avoided were the client consistently to include the MTU of the=20 link layer interface. But clients cannot be expected to be omniscient=20 about other media over which packets travel en route to servers. Servers that must be endowed with this knowledge, which they MUST use=20 to avoid packet fragmentation.=20 Once the IP stack is configured, and the IP stack is fully=20 configured, the aforementioned limitation ceases to exist, and later=20 stages of the protocol could allow larger packets (up to the UDP limit). DHCPINFORMs, especially, could benefit from this relaxation. =20 There probably should be explicit text to allow larger packets=20 (presumably up to the maximum PDU size) for later stages of the=20 protocol.=20 A number of clients send small packets with the assumption that=20 servers will not return a packet that is any larger than the one received from the client. The client MUST NOT make this assumption.=20 If the client cannot process a response larger than a certain size,=20 the client MUST use the message size option to inform servers of this=20 size. Note that this is NOT the same option as the MTU.=20 RECOMMENDATIONS:=20 o Servers and relay agents MUST ensure that IP datagram=20 fragmentation does not occur at any stage in the protocol=20 before the client IP stack is fully configured.=20 o Clients SHOULD communicate their link-layer frame size to the DHCP server via the DHCP MTU option.=20 o Clients MUST NOT assume that servers will return a packet no=20 larger than the one they send. If the client has a limit on the=20 size of the packet that it can process it MUST convey that=20 limit to the server in the "maximum message size" option (57) o Page 21, second paragraph, section 3.5, the first sentence=20 SHOULD be changed to "The client SHOULD include the 'maximum=20 DHCP message size' option to let the server know how large the=20 server may make its DHCP messages, and the value of this option=20 SHOULD be the MTU of the [client] network interface being=20 configured."=20 o The WORKING GROUP SHOULD consider whether to allow=20 fragmentation of packets after the client is fully configured,=20 and how servers can divine this fact (e.g. a non-zero=20 "ciaddr"). =20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of David W. Hankins > Sent: Friday, May 06, 2005 2:53 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. >=20 > On Fri, May 06, 2005 at 12:09:31PM +0100, Simon Kelley wrote: > > Does the value in "maximum message size" option (option=20 > code 56) include=20 > > the IP and UDP headers? > >=20 > > Neither RFC2131 or RFC2132 ever state this explicitly, but they are=20 > > self-consistent if it's the case. RFC2132 states that the=20 > minimum legal=20 > > value is 576 octets, which equals IP header + UDP header +=20 > fixed DHCP=20 > > fields + the minimum 312 octet options field specified in RFC2131. >=20 > To add to your confusion, ISC DHCP calculates this as: >=20 > 'mms' - (ethernet + ip + udp + dhcp header sizes) >=20 > Should the 'mms' be less than 576, we use 576. >=20 > I suspect our inclusion of the ethernet header size in this=20 > calculation > is incorrect, since as you mention it doesn't add up if you=20 > use a 312 byte > options field. >=20 > > I ask because I've just come across a client which=20 > advertises a maximum=20 > > message size of 548. Presumably this is broken, and there's=20 > a chance=20 > > that the client is also misinterpreting a "576" maximum=20 > message size=20 > > option _from_ a DHCP server and could potentially try and=20 > use 28 bytes=20 > > that the server cannot receive. >=20 > As I mentioned above, I believe our DHCP server would simply=20 > not observe > this mms, and pretend as though it was not supplied. >=20 > > If the wise ones here can confirm that this really is an=20 > RFC violation,=20 > > I'll submit a bug report to the vendor of the client. >=20 > I have no such wisdom. >=20 > --=20 > David W. Hankins "If you don't do it right the=20 > first time, > Software Engineer you'll just have to do=20 > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 07 07:56:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUNvV-0003Iu-Uc; Sat, 07 May 2005 07:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUNvU-0003Ip-NF for dhcwg@megatron.ietf.org; Sat, 07 May 2005 07:56:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03076 for ; Sat, 7 May 2005 07:56:55 -0400 (EDT) Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUOAA-0003o0-VM for dhcwg@ietf.org; Sat, 07 May 2005 08:12:08 -0400 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 17955467; Sat, 07 May 2005 13:56:53 +0200 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. Date: Sat, 7 May 2005 13:35:26 +0200 User-Agent: KMail/1.6.2 References: <427B506B.1050005@thekelleys.org.uk> In-Reply-To: <427B506B.1050005@thekelleys.org.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505071335.26787.budm@weird-solutions.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Friday 06 May 2005 13:09, Simon Kelley wrote: > Does the value in "maximum message size" option (option code 56) include > the IP and UDP headers? This has been brought up before, since it's not obvious from the specs, and the general consensus IIRC is "yes". I think most DHCP servers by now will (correctly) subtract ip+udp header sizes from the value the client advertises. And for David: I seem to recall that the ISC DHCP server uses some type of raw interface to the network layer; might the ethernet header size be included for that reason? Regards, Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 07 11:54:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURdr-0002nB-5a; Sat, 07 May 2005 11:54:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURdp-0002mN-Kn for dhcwg@megatron.ietf.org; Sat, 07 May 2005 11:54:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23511 for ; Sat, 7 May 2005 11:54:55 -0400 (EDT) Received: from cpc4-cmbg4-4-0-cust135.cmbg.cable.ntl.com ([81.108.205.135] helo=thekelleys.org.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DURsY-0004Wy-TU for dhcwg@ietf.org; Sat, 07 May 2005 12:10:11 -0400 Received: from desk.thekelleys.org.uk ([192.168.0.3] helo=thekelleys.org.uk) by thekelleys.org.uk with esmtp (Exim 3.35 #1 (Debian)) id 1DURdc-0000Tt-00; Sat, 07 May 2005 16:54:44 +0100 Message-ID: <427CE4D5.2020002@thekelleys.org.uk> Date: Sat, 07 May 2005 16:55:01 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "Bernie Volz (volz)" Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. References: <8E296595B6471A4689555D5D725EBB2122D41B@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2122D41B@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie Volz (volz) wrote: > It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has > expired. See text below. The key part is: That's a valuable document which I'd not come across before, thanks. In case is ever gets revived, I have an addition to section 2.21, "Option Ordering" >A number of clients exist that require that the DHCP message type be >the first option (after the magic cookie). We SHOULD restate that >the client MUST NOT make any such assumption. The only known >ordering constraint concerns option 82, which is last. CMTS vendors >want it to be last, but suppose someone else wants their pet option >to be last also -- how would we resolve this conflict? There's at least on widely deployed client (The Intel PXE client) which depends on option 60 (vendor class identifier) preceeding option 43 (Vendor specific information.) So that's another constraint to add to the list. > o Clients SHOULD communicate their link-layer frame size to the > > DHCP server via the DHCP MTU option. > > So, this is *LINK-LAYER* frame size. > > I believe this 576 size comes from RFC 791: > > Total Length: 16 bits > > Total Length is the length of the datagram, measured in octets, > including internet header and data. This field allows the length of > a datagram to be up to 65,535 octets. Such long datagrams are > impractical for most hosts and networks. All hosts must be prepared > to accept datagrams of up to 576 octets (whether they arrive whole > or in fragments). It is recommended that hosts only send datagrams > larger than 576 octets if they have assurance that the destination > is prepared to accept the larger datagrams. > > The number 576 is selected to allow a reasonable sized data block to > be transmitted in addition to the required header information. For > example, this size allows a data block of 512 octets plus 64 header > octets to fit in a datagram. The maximal internet header is 60 > octets, and a typical internet header is 20 octets, allowing a > margin for headers of higher level protocols. > > So, it should be treated as the "IP + UDP + DHCP" packet size. > That's clear, I'll log a bug report against the client which sends a Max. message of 548. Cheers, Simon. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 07 12:04:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURn9-0003kp-Jo; Sat, 07 May 2005 12:04:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURn8-0003kk-I4 for dhcwg@megatron.ietf.org; Sat, 07 May 2005 12:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24064 for ; Sat, 7 May 2005 12:04:32 -0400 (EDT) Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DUS1p-0004uQ-Li for dhcwg@ietf.org; Sat, 07 May 2005 12:19:48 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.226 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 7 May 2005 16:04:27 -0000 From: "Barr Hibbs" To: "Bernie Volz \(volz\)" , "David W. Hankins" , "Simon Kelley" Subject: RE: [dhcwg] DHCPv4 - definition of maximum message size. Date: Sat, 7 May 2005 09:04:27 -0700 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.6604 (9.0.2911.0) In-Reply-To: <8E296595B6471A4689555D5D725EBB2122D41B@xmb-rtp-20a.amer.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rbhibbs@pacbell.net List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org funny you should bring that up, Bernie... I was just thinking the other day that I ought to poll Rob again to see if he's up to the task of finishing the work on this draft, since I believe that it's still needed to complete the standardization process of DHCPv4.... --Barr > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]On Behalf Of > Bernie Volz (volz) > Sent: Friday, May 06, 2005 12:06 > To: David W. Hankins; Simon Kelley > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] DHCPv4 - definition of maximum message size. > > > It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has > expired. See text below. The key part is: > o Clients SHOULD communicate their link-layer frame size to the > > DHCP server via the DHCP MTU option. > > So, this is *LINK-LAYER* frame size. > > I believe this 576 size comes from RFC 791: > > Total Length: 16 bits > > Total Length is the length of the datagram, measured in octets, > including internet header and data. This field allows the length of > a datagram to be up to 65,535 octets. Such long datagrams are > impractical for most hosts and networks. All hosts must be prepared > to accept datagrams of up to 576 octets (whether they arrive whole > or in fragments). It is recommended that hosts only send datagrams > larger than 576 octets if they have assurance that the destination > is prepared to accept the larger datagrams. > > The number 576 is selected to allow a reasonable sized data block to > be transmitted in addition to the required header information. For > example, this size allows a data block of 512 octets plus 64 header > octets to fit in a datagram. The maximal internet header is 60 > octets, and a typical internet header is 20 octets, allowing a > margin for headers of higher level protocols. > > So, it should be treated as the "IP + UDP + DHCP" packet size. > > --- > > 2.19. Size of a BOOTP/DHCP frame > > The description in RFC 2131 relating to the size constraints of > DHCP > packets (Page 10, first paragraph after Table 1, section 2) is > inadequate. > > > 2.19.1. Minimum size. > > RFC 951 states that a minimum BOOTP frame is 300 octets in > length. > Some BOOTP relay agents have been known to drop frames of less > than > 300 octets. RFC 951 is explicit on this point, but RFC 2131 > just > refers to RFC 951. Since DHCP is intended to be backward > compatible > with BOOTP, the protocol should continue to observe this lower > bound. > > RECOMMENDATIONS: > > o Text should be added stating explicitly that the minimum size > > of a DHCP frame is 300 octets. > > > 2.19.2. Maximum Size, MTU, and Message Size option > > It has been thought necessary to avoid fragmentation of the IP > packets in DHCP/BOOTP due to concerns that some clients would be > > unable to reassemble fragments before the IP stack is properly > configured. RFC 951 states "For simplicity it is assumed that > the > BOOTP packet is never fragmented". Regardless of theoretical > limitations in IP stack implementations, it is certain that > there are > several DHCP/BOOTP implementations, at both ends of the > protocol, > which will not reassemble. > > Various comments in the WORKING GROUP imply that fragmentation > could > be avoided were the client consistently to include the MTU of > the > link layer interface. But clients cannot be expected to be > omniscient > about other media over which packets travel en route to servers. > > Servers that must be endowed with this knowledge, which they > MUST use > to avoid packet fragmentation. > > Once the IP stack is configured, and the IP stack is fully > configured, the aforementioned limitation ceases to exist, and > later > stages of the protocol could allow larger packets (up to the UDP > > limit). DHCPINFORMs, especially, could benefit from this > relaxation. > There probably should be explicit text to allow larger packets > (presumably up to the maximum PDU size) for later stages of the > protocol. > > A number of clients send small packets with the assumption that > servers will not return a packet that is any larger than the one > > received from the client. The client MUST NOT make this > assumption. > If the client cannot process a response larger than a certain > size, > the client MUST use the message size option to inform servers of > this > size. Note that this is NOT the same option as the MTU. > > RECOMMENDATIONS: > > o Servers and relay agents MUST ensure that IP datagram > fragmentation does not occur at any stage in the protocol > before the client IP stack is fully configured. > > o Clients SHOULD communicate their link-layer frame size to the > > DHCP server via the DHCP MTU option. > > o Clients MUST NOT assume that servers will return a packet no > larger than the one they send. If the client has a limit on > the > size of the packet that it can process it MUST convey that > limit to the server in the "maximum message size" option (57) > > > o Page 21, second paragraph, section 3.5, the first sentence > SHOULD be changed to "The client SHOULD include the 'maximum > DHCP message size' option to let the server know how large > the > server may make its DHCP messages, and the value of this > option > SHOULD be the MTU of the [client] network interface being > configured." > > o The WORKING GROUP SHOULD consider whether to allow > fragmentation of packets after the client is fully > configured, > and how servers can divine this fact (e.g. a non-zero > "ciaddr"). > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of David W. Hankins > > Sent: Friday, May 06, 2005 2:53 PM > > To: dhcwg@ietf.org > > Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. > > > > On Fri, May 06, 2005 at 12:09:31PM +0100, Simon Kelley wrote: > > > Does the value in "maximum message size" option (option > > code 56) include > > > the IP and UDP headers? > > > > > > Neither RFC2131 or RFC2132 ever state this explicitly, but they are > > > self-consistent if it's the case. RFC2132 states that the > > minimum legal > > > value is 576 octets, which equals IP header + UDP header + > > fixed DHCP > > > fields + the minimum 312 octet options field specified in RFC2131. > > > > To add to your confusion, ISC DHCP calculates this as: > > > > 'mms' - (ethernet + ip + udp + dhcp header sizes) > > > > Should the 'mms' be less than 576, we use 576. > > > > I suspect our inclusion of the ethernet header size in this > > calculation > > is incorrect, since as you mention it doesn't add up if you > > use a 312 byte > > options field. > > > > > I ask because I've just come across a client which > > advertises a maximum > > > message size of 548. Presumably this is broken, and there's > > a chance > > > that the client is also misinterpreting a "576" maximum > > message size > > > option _from_ a DHCP server and could potentially try and > > use 28 bytes > > > that the server cannot receive. > > > > As I mentioned above, I believe our DHCP server would simply > > not observe > > this mms, and pretend as though it was not supplied. > > > > > If the wise ones here can confirm that this really is an > > RFC violation, > > > I'll submit a bug report to the vendor of the client. > > > > I have no such wisdom. > > > > -- > > David W. Hankins "If you don't do it right the > > first time, > > Software Engineer you'll just have to do > > it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > > _______________________________________________ > 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-bounces@ietf.org Sat May 07 12:07:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURpj-00045W-DP; Sat, 07 May 2005 12:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURpi-00045R-Lu for dhcwg@megatron.ietf.org; Sat, 07 May 2005 12:07:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24333 for ; Sat, 7 May 2005 12:07:12 -0400 (EDT) Received: from smtp803.mail.sc5.yahoo.com ([66.163.168.182]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DUS4R-00052N-Lr for dhcwg@ietf.org; Sat, 07 May 2005 12:22:28 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.226 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 7 May 2005 16:07:10 -0000 From: "Barr Hibbs" To: "Simon Kelley" , "Bernie Volz \(volz\)" Subject: RE: [dhcwg] DHCPv4 - definition of maximum message size. Date: Sat, 7 May 2005 09:07:10 -0700 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.6604 (9.0.2911.0) In-Reply-To: <427CE4D5.2020002@thekelleys.org.uk> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rbhibbs@pacbell.net List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org yet another argument for revising the draft... wonder if Rob and I can make the deadline for the Paris IETF meeting (not that *I* can attend, darn it!) --Barr > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]On Behalf Of > Simon Kelley > Sent: Saturday, May 07, 2005 08:55 > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. > > > Bernie Volz (volz) wrote: > > It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has > > expired. See text below. The key part is: > > That's a valuable document which I'd not come across before, thanks. > > In case is ever gets revived, I have an addition to section 2.21, > "Option Ordering" > > >A number of clients exist that require that the DHCP message type be > >the first option (after the magic cookie). We SHOULD restate that > >the client MUST NOT make any such assumption. The only known > >ordering constraint concerns option 82, which is last. CMTS vendors > >want it to be last, but suppose someone else wants their pet option > >to be last also -- how would we resolve this conflict? > > There's at least on widely deployed client (The Intel PXE client) which > depends on option 60 (vendor class identifier) preceeding option 43 > (Vendor specific information.) So that's another constraint to add to > the list. > > > > > o Clients SHOULD communicate their link-layer frame size to the > > > > DHCP server via the DHCP MTU option. > > > > So, this is *LINK-LAYER* frame size. > > > > I believe this 576 size comes from RFC 791: > > > > Total Length: 16 bits > > > > Total Length is the length of the datagram, measured in octets, > > including internet header and data. This field allows the length of > > a datagram to be up to 65,535 octets. Such long datagrams are > > impractical for most hosts and networks. All hosts must be prepared > > to accept datagrams of up to 576 octets (whether they arrive whole > > or in fragments). It is recommended that hosts only send datagrams > > larger than 576 octets if they have assurance that the destination > > is prepared to accept the larger datagrams. > > > > The number 576 is selected to allow a reasonable sized data block to > > be transmitted in addition to the required header information. For > > example, this size allows a data block of 512 octets plus 64 header > > octets to fit in a datagram. The maximal internet header is 60 > > octets, and a typical internet header is 20 octets, allowing a > > margin for headers of higher level protocols. > > > > So, it should be treated as the "IP + UDP + DHCP" packet size. > > > > That's clear, I'll log a bug report against the client which sends a > Max. message of 548. > > Cheers, > > Simon. > > _______________________________________________ > 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-bounces@ietf.org Sat May 07 14:02:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUTdZ-0001S0-ME; Sat, 07 May 2005 14:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURiQ-0003SJ-1L for dhcwg@megatron.ietf.org; Sat, 07 May 2005 11:59:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23791 for ; Sat, 7 May 2005 11:59:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DURx6-0004iS-NU for dhcwg@ietf.org; Sat, 07 May 2005 12:14:55 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 May 2005 12:13:36 -0400 X-IronPort-AV: i="3.92,164,1112587200"; d="txt'?scan'208"; a="48198964:sNHT94381644" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j47FxQnI012256; Sat, 7 May 2005 11:59:27 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 May 2005 11:59:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5531D.B98A561E" Subject: RE: [dhcwg] DHCPv4 - definition of maximum message size. Date: Sat, 7 May 2005 11:59:24 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2122D4C4@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: yes Thread-Topic: [dhcwg] DHCPv4 - definition of maximum message size. Thread-Index: AcVTHRnnp9O1ZqVuQTSuh2RU5d/10QAAGAng From: "Bernie Volz \(volz\)" To: "Simon Kelley" , "Barr Hibbs" X-OriginalArrivalTime: 07 May 2005 15:59:26.0554 (UTC) FILETIME=[BE860BA0:01C5531D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a86d33a82239593e1ae3128a5eda063 X-Mailman-Approved-At: Sat, 07 May 2005 14:02:45 -0400 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5531D.B98A561E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah, if Barr doesn't want to continue work on this document, it would be good to get someone to take it on. You willing to volunteer (assuming Barr isn't interested)? I do have a copy of the latest version Barr submitted (which is attached). - Bernie=20 > -----Original Message----- > From: Simon Kelley [mailto:simon@thekelleys.org.uk]=20 > Sent: Saturday, May 07, 2005 11:55 AM > To: Bernie Volz (volz) > Cc: David W. Hankins; dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. >=20 > Bernie Volz (volz) wrote: > > It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has > > expired. See text below. The key part is: >=20 > That's a valuable document which I'd not come across before, thanks. >=20 > In case is ever gets revived, I have an addition to section 2.21,=20 > "Option Ordering" >=20 > >A number of clients exist that require that the DHCP message type be > >the first option (after the magic cookie). We SHOULD restate that > >the client MUST NOT make any such assumption. The only known > >ordering constraint concerns option 82, which is last. CMTS vendors > >want it to be last, but suppose someone else wants their pet option > >to be last also -- how would we resolve this conflict? >=20 > There's at least on widely deployed client (The Intel PXE=20 > client) which > depends on option 60 (vendor class identifier) preceeding option 43 > (Vendor specific information.) So that's another constraint to add to > the list. >=20 >=20 >=20 > > o Clients SHOULD communicate their link-layer=20 > frame size to the > >=20 > > DHCP server via the DHCP MTU option.=20 > >=20 > > So, this is *LINK-LAYER* frame size. > >=20 > > I believe this 576 size comes from RFC 791: > >=20 > > Total Length: 16 bits > >=20 > > Total Length is the length of the datagram, measured in octets, > > including internet header and data. This field allows=20 > the length of > > a datagram to be up to 65,535 octets. Such long datagrams are > > impractical for most hosts and networks. All hosts=20 > must be prepared > > to accept datagrams of up to 576 octets (whether they=20 > arrive whole > > or in fragments). It is recommended that hosts only=20 > send datagrams > > larger than 576 octets if they have assurance that the=20 > destination > > is prepared to accept the larger datagrams. > >=20 > > The number 576 is selected to allow a reasonable sized=20 > data block to > > be transmitted in addition to the required header=20 > information. For > > example, this size allows a data block of 512 octets=20 > plus 64 header > > octets to fit in a datagram. The maximal internet header is 60 > > octets, and a typical internet header is 20 octets, allowing a > > margin for headers of higher level protocols. > >=20 > > So, it should be treated as the "IP + UDP + DHCP" packet size. > >=20 >=20 > That's clear, I'll log a bug report against the client which sends a=20 > Max. message of 548. >=20 > Cheers, >=20 > Simon. >=20 ------_=_NextPart_001_01C5531D.B98A561E Content-Type: text/plain; name="draft-ietf-dhc-implementation-01.txt" Content-Description: draft-ietf-dhc-implementation-01.txt Content-Disposition: attachment; filename="draft-ietf-dhc-implementation-01.txt" Content-Transfer-Encoding: base64 CgogICAgIE5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQmFyciBIaWJicyAKICAgICBJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChubyBhZmZpbGlhdGlvbikgCiAgICAgQ2F0ZWdv cnk6ICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv YiBTdGV2ZW5zIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG5vIGFmZmlsaWF0aW9uKSAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDMgCiAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICBJbXBsZW1lbnRhdGlvbiBJc3N1ZXMgd2l0aCBSRkMgMjEzMSwgIkR5bmFtaWMgSG9zdCBDb25m aWd1cmF0aW9uIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFByb3RvY29s IiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoKICAgICAgICAg ICAgICAgICAgICAgICA8ZHJhZnQtaWV0Zi1kaGMtaW1wbGVtZW50YXRpb24tMDEudHh0PiAKICAg ICAgICAgIFNhdmVkIEZyaWRheSwgT2N0b2JlciAyNCwgMjAwMywgODowODoxNSBBTTg6MDU6NTYg QU0gUFQ4OjA4OjE1IEFNIAoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAoKICAgICBTdGF0dXMgb2YgdGhpcyBNZW1vIAoKICAgICAgICBUaGlzIGRvY3VtZW50IGlz IGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggCiAgICAg ICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2LiAKCiAgICAgICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcgCiAgICAgICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCAKICAgICAgICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgICAgICBEcmFmdHMuIAoK ICAgICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHMgCiAgICAgICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgCiAgICAgICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2Ug CiAgICAgICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIiAKCiAgICAgICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0IAogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvMWlkLWFic3Ry YWN0cy5odG1sLiAKCiAgICAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERp cmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCAKICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sLiAKCiAgICAgQ29weXJpZ2h0IE5vdGljZSAKCiAgICAgICAgQ29weXJpZ2h0 IChDKSAyMDAzLCBUaGUgSW50ZXJuZXQgU29jaWV0eS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIAoK ICAgICBBYnN0cmFjdCAKCiAgICAgICAgVGhpcyBtZW1vIGlkZW50aWZpZXMgaW1wbGVtZW50YXRp b24gaXNzdWVzIHdpdGggUkZDIDIxMzEsICJEeW5hbWljIAogICAgICAgIEhvc3QgQ29uZmlndXJh dGlvbiBQcm90b2NvbCwiIHJlcG9ydGVkIGJ5IGEgbnVtYmVyIG9mIGltcGxlbWVudGVycywgCiAg ICAgICAgYXNzZXNzZXMgdGhlIHNldmVyaXR5IG9mIHRoZSBwcm9ibGVtLCB0aGVuIHByb3Bvc2Vz IGNoYW5nZXMgdG8gUkZDIAogICAgICAgIDIxMzEgaW50ZW5kZWQgdG8gb3ZlcmNvbWUgdGhlIGlz c3Vlcy4gIFRoaXMgaXMgaW50ZW5kZWQgZm9yIHVzZSBhcyAKICAgICAgICB0aGUgYmFzaXMgZm9y IGRpc2N1c3Npb24gb2YgUkZDIDIxMzEgYmVmb3JlIGl0IGlzIHByb3Bvc2VkIGZvciAKICAgICAg ICBJbnRlcm5ldCBTdGFuZGFyZCBzdGF0dXMuIAoKICAgICAgICAgCgogICAgICAKICAgICBIaWJi cyAmIFN0ZXZlbnMgICAgICAgRXhwaXJlczogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAgICAgICAg ICAgW1BhZ2UgMV0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgICBSRkMgMjEz MSBJbXBsZW1lbnRhdGlvbiBJc3N1ZXMgICAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAg IFRhYmxlIG9mIENvbnRlbnRzIAoKICAgICAgICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIAogICAgICAgIDIuIElzc3Vl cyB3aXRoIFJGQyAyMTMxLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjMgCiAgICAgICAgICAyLjEuIE91dGRhdGVkIFJGQyBCb2lsZXJwbGF0ZS4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMyAKICAgICAgICAgIDIuMi4gT3JnYW5pemF0aW9uIGFuZCBU eXBvZ3JhcGh5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IAogICAgICAgICAgICAy LjIuMS4gT3V0ZGF0ZWQgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNCAKICAgICAgICAgICAgMi4yLjIuIFR5cG9ncmFwaGljYWwgRXJyb3JzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgCiAgICAgICAgICAgIDIuMi4zLiBPbWlzc2lvbnMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IAogICAgICAgICAgICAy LjIuNC4gVGFibGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNSAKICAgICAgICAgICAgMi4yLjUuIEluY29uc2lzdGVuY2llcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgCiAgICAgICAgICAyLjMuIFBvbGljeSBpc3N1ZXMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNiAKICAgICAgICAgIDIu NC4gVGhlIENsaWVudCBIYXJkd2FyZSBBZGRyZXNzLCAiY2hhZGRyIi4uLi4uLi4uLi4uLi4uLi4u Li4uLi43IAogICAgICAgICAgMi41LiBUaGUgREhDUCBDbGllbnQgSWRlbnRpZmllci4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgCiAgICAgICAgICAgIDIuNS4xLiBVbmlxdWVuZXNz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IAogICAgICAgICAg ICAyLjUuMi4gUHJvaGliaXRpb24gaW4gREhDUE9GRkVSIGFuZCBESENQQUNLLi4uLi4uLi4uLi4u Li4uLi4uOCAKICAgICAgICAgIDIuNi4gQWRkcmVzcy1pbi1Vc2UgRGV0ZWN0aW9uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IAogICAgICAgICAgICAyLjYuMS4gQ2xpZW50LXNp ZGUgQVJQLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSAKICAgICAgICAg ICAgMi42LjIuIFNlcnZlciBzaWRlIFBJTkcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjkgCiAgICAgICAgICAgIDIuNi4zLiBPdGhlciBNZWNoYW5pc21zLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIAogICAgICAgICAgMi43LiBESENQIFJlbGF5IEFn ZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTAgCiAgICAgICAg ICAgIDIuNy4xLiBSZWxheSBBZ2VudCBTb3VyY2UgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjEwIAogICAgICAgICAgICAyLjcuMi4gUmVsYXkgQWdlbnQgUG9ydCBVc2FnZS4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCAKICAgICAgICAgIDIuOC4gSG9zdCBOYW1lLCBE b21haW4gTmFtZSwgYW5kIEZRRE5zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExIAogICAgICAg ICAgMi45LiBPdmVybG9hZGluZyBvZiBESENQUkVRVUVTVC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTEgCiAgICAgICAgICAyLjEwLiBESENQSU5GT1JNLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSAKICAgICAgICAgIDIuMTEuIFVuaWNhc3Qg b2YgREhDUERJU0NPVkVSLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyIAogICAg ICAgICAgMi4xMi4gREhDUFJFTEVBU0UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTMgCiAgICAgICAgICAyLjEzLiBDbGllbnQgc3RhdGUgZGlhZ3JhbS4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyAKICAgICAgICAgIDIuMTQuIE9wdGlv bnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzIAog ICAgICAgICAgICAyLjE0LjEuIFdoaWNoIE9wdGlvbnMgdG8gUmV0dXJuPy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xNCAKICAgICAgICAgICAgMi4xNC4yLiBNdWx0aXBsZSBJbnN0YW5jZXMg b2YgT3B0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYgCiAgICAgICAgICAgIDIuMTQuMy4g T3B0aW9uIE9yZGVyaW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2IAog ICAgICAgICAgICAyLjE0LjQuIE9wdGlvbnMgNjYgYW5kIDY3Li4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xNiAKICAgICAgICAgIDIuMTUuIFZlbmRvciBDbGFzc2VzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3IAogICAgICAgICAgICAyLjE1LjEu IENoYXJhY3RlciBzZXQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNyAK ICAgICAgICAgICAgMi4xNS4yLiBGb3JtIG9mIHRoZSBuYW1lIHNwYWNlLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTcgCiAgICAgICAgICAgIDIuMTUuMy4gUmVsYXRpb25zaGlwIHRvIHZl bmRvciBvcHRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3IAogICAgICAgICAgICAyLjE1LjQu IE11bHRpcGxpY2l0eS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOCAK ICAgICAgICAgIDIuMTYuIENsaWVudC9TZXJ2ZXIgUmV0cmFuc21pc3Npb24uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjE5IAogICAgICAgICAgMi4xNy4gVHJhbnNtaXNzaW9uIG9mIERIQ1BO QUtzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkgCiAgICAgICAgICAyLjE4LiBV c2Ugb2YgY2lhZGRyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4y MCAKICAgICAgICAgIDIuMTkuIFNpemUgb2YgYSBCT09UUC9ESENQIGZyYW1lLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjIwIAogICAgICAgICAgICAyLjE5LjEuIE1pbmltdW0gc2l6ZS4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMCAKICAgICAgICAgICAgMi4x OS4yLiBNYXhpbXVtIFNpemUsIE1UVSwgYW5kIE1lc3NhZ2UgU2l6ZSBvcHRpb24uLi4uLi4uLi4u MjAgCiAgICAgICAgICAyLjIwLiBVc2Ugb2YgZ2lhZGRyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yMiAKICAgICAgICAgIDIuMjEuIEFkZHJlc3MgU2VsZWN0aW9u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIyIAogICAgICAgICAgMi4y Mi4gVXNlIG9mICJzZWNzIiBmaWVsZC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMjIgCiAgICAgICAgICAyLjIzLiBVc2Ugb2YgImh0eXBlIiBhbmQgImhsZW4iIGZpZWxkcy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyAKICAgICAgICAgIDIuMjQuIFVzZSBvZiB4aWQgZmll bGQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIzIAogICAgICAKICAg ICBIaWJicyAmIFN0ZXZlbnMgICAgICAgRXhwaXJlczogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAg ICAgICAgICAgW1BhZ2UgMl0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJG QyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAog ICAgICAgICAgMi4yNS4gT3B0aW9ucyBpbiBESENQT0ZGRVIgYW5kIERIQ1BBQ0suLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjQgCiAgICAgICAgICAyLjI2LiBMZWFzZSB0aW1lcy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNCAKICAgICAgICAgIDIuMjcuIE1p c2NlbGxhbmVvdXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI1 IAogICAgICAgIDMuIEludGVsbGVjdHVhbCBQcm9wZXJ0eS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMjYgCiAgICAgICAgNC4gTm90ZXMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNiAKICAgICAgICAgIDQuMS4g SXNzdWVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjI2IAogICAgICAgICAgNC4yLiBDaGFuZ2VzIGZyb20gUHJpb3IgRHJhZnRzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMjcgCiAgICAgICAgNS4gQWNrbm93bGVkZ2VtZW50cy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOCAKICAgICAgICA2LiBJ QU5BIENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjI4IAogICAgICAgIDcuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjggCiAgICAgICAgOC4gUmVmZXJlbmNlcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOCAKICAgICAgICA5 LiBFZGl0b3JzJyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjI5IAogICAgICAgIDEwLiBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjkgCiAgICAgICAgIAoKCiAgICAgMS4gSW50cm9k dWN0aW9uIAoKICAgICAgICBUaGlzIG1lbW8gd2FzIHByb2R1Y2VkIGJ5IHRoZSBESEMgV29ya2lu ZyBHcm91cCBhbmQgYXR0ZW1wdHMgdG8gCiAgICAgICAgaWRlbnRpZnkgYWxsIGtub3duIGltcGxl bWVudGF0aW9uIGlzc3VlcyB3aXRoIFJGQyAyMTMxIGFzIGEgYmFzaXMgZm9yIAogICAgICAgIGRp c2N1c3Npb24gb2YgUkZDIDIxMzEgYmVmb3JlIGl0IGlzIHB1Ymxpc2hlZCBhcyBhbiBJbnRlcm5l dCAKICAgICAgICBTdGFuZGFyZC4gCgogICAgICAgIFRoaXMgbWVtbyBncmV3IGZyb20gYSBkaXNj dXNzaW9uIGl0ZW0gZHVyaW5nIHRoZSBESEMgV29ya2luZyBHcm91cCAKICAgICAgICBtZWV0aW5n IGF0IElFVEYtNTUgaW4gQXRsYW50YSBkdXJpbmcgTm92ZW1iZXIgMjAwMi4gCgogICAgICAgIFRo ZSBlZGl0b3JzIGhhdmUgc29saWNpdGVkIGlucHV0IHRocm91Z2ggYSBnZW5lcmFsIGNhbGwgZm9y IAogICAgICAgIHBhcnRpY2lwYXRpb24gYW5kIGJ5IGRpcmVjdCByZXF1ZXN0IHRvIGFsbCBpbXBs ZW1lbnRlcnMgdGhhdCB0aGV5IAogICAgICAgIGNvdWxkIGlkZW50aWZ5IAoKICAgICAgICBUaGUg a2V5IHdvcmRzICJNVVNULCIgIk1VU1QgTk9ULCIgIlJFUVVJUkVELCIgIlNIQUxMLCIgIlNIQUxM IE5PVCwiIAogICAgICAgICJTSE9VTEQsIiAiU0hPVUxEIE5PVCwiICJSRUNPTU1FTkRFRCwiICJN QVksIiBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIAogICAgICAgIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gZG9jdW1lbnQgW1JGQzIxMTldLiAKCgogICAgIDIu IElzc3VlcyB3aXRoIFJGQyAyMTMxIAoKICAgICAgICBUaGlzIGxpc3QgbWF5IG5vdCBpbmNsdWRl IGV2ZXJ5IGltcGxlbWVudGF0aW9uIGlzc3VlIGZvciBSRkMgMjEzMSBhcyAKICAgICAgICBpdCBp cyBiYXNlZCBvbiByZXBvcnRlZCBwcm9ibGVtcyBhbmQgdGhvc2Uga25vd24gdG8gdGhlIGVkaXRv cnMuIAoKCiAgICAgMi4xLiBPdXRkYXRlZCBSRkMgQm9pbGVycGxhdGUgCgogICAgICAgIDEuICAi U3RhdHVzIG9mIFRoaXMgTWVtbyIgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggc3RhbmRhcmRpemVk IAogICAgICAgICAgICBsYW5ndWFnZSBmb3IgUkZDcyBhcyBkZXNjcmliZWQgaW4gIkd1aWRlbGlu ZXMgdG8gQXV0aG9ycyBvZiAKICAgICAgICAgICAgSW50ZXJuZXQtRHJhZnRzLCIgZGF0ZWQgU2Vw dGVtYmVyIDUsIDIwMDIuIAoKICAgICAgICAyLiAgU2VjdGlvbiAxLjQsICJSZXF1aXJlbWVudHMs IiBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBzdGFuZGFyZGl6ZWQgCiAgICAgICAgICAgIGxhbmd1 YWdlIHJlZmVycmluZyB0byBSRkMgMjExOSByZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gYW5kIAog ICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiBzcGVjaWZpYyBrZXkgd29yZHMuIAogICAgICAK ICAgICBIaWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAg ICAgICAgICAgW1BhZ2UgM10gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJG QyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAog ICAgICAgIDMuICBSZWZlcmVuY2VzIHNob3VsZCBiZSBzZXBhcmF0ZWQgaW50byBub3JtYXRpdmUg YW5kIG5vbi1ub3JtYXRpdmUgCiAgICAgICAgICAgIHNlY3Rpb25zLiAKCgogICAgIDIuMi4gT3Jn YW5pemF0aW9uIGFuZCBUeXBvZ3JhcGh5IAoKCiAgICAgMi4yLjEuIE91dGRhdGVkIFJlZmVyZW5j ZXMgCgogICAgICAgIDEuICBSZWZlcmVuY2VzIHRvIHRoZSAiQXNzaWduZWQgTnVtYmVycyIgUkZD IFtTVEQgMiwgUkZDIDE3MDBdIAogICAgICAgICAgICBzaG91bGQgYmUgY2hhbmdlZCB0byB0aGUg IkFzc2lnbmVkIE51bWJlcnMiIGRhdGFiYXNlIAogICAgICAgICAgICBtYWludGFpbmVkIGJ5IElB TkEuICBSZWZlcmVuY2VzIGFyZSBmb3VuZCBpbiBUYWJsZXMgMyBhbmQgNSwgCiAgICAgICAgICAg IGFuZCBpbiB0aGUgIlJlZmVyZW5jZXMiIHNlY3Rpb24uIAoKICAgICAgICAyLiAgUmVmZXJlbmNl cyB0byB0aGUgIkludGVyYWN0aW9uIGJldHdlZW4gREhDUCBhbmQgQk9PVFAiIFJGQyAKICAgICAg ICAgICAgMTUzNCBzaG91bGQgYmUgaW50ZWdyYXRlZCB3aXRoIHRoZSB0ZXh0IG9mIHRoZSBtZW1v LCBhbmQgUkZDIAogICAgICAgICAgICAxNTM0IGRlcHJlY2F0ZWQuIAoKCiAgICAgMi4yLjIuIFR5 cG9ncmFwaGljYWwgRXJyb3JzIAoKICAgICAgICAxLiAgUGFnZSAyMywgdGhpcmQgcGFyYWdyYXBo IG9mIHNlY3Rpb24gNC4xIC0tICJyZWNpZXZlZCIgc2hvdWxkIAogICAgICAgICAgICBiZSAicmVj ZWl2ZWQuIiAKCiAgICAgICAgMi4gIFBhZ2UgMjMsIHNpeHRoIHBhcmFncmFwaCBvZiBzZWN0aW9u IDQuMSAtLSByZWZlcnMgdG8gUkZDIDE1MzMsIAogICAgICAgICAgICBub3QgUkZDIDIxMzIuIAoK ICAgICAgICAzLiAgUGFnZSAxNSwgRmlndXJlIDMuICBUYWJsZSBtaXNmb3JtYXR0ZWQuIAoKICAg ICAgICA0LiAgUGFnZSAxOCwgRmlndXJlIDQuICBUYWJsZSBtaXNmb3JtYXR0ZWQuIAoKICAgICAg ICA1LiAgUGFnZSAyNSwgbmludGggcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC4xIC0tICJ1aWNhc3Qi IHNob3VsZCBiZSAKICAgICAgICAgICAgInVuaWNhc3QuIiAKCiAgICAgICAgNi4gIFBhZ2UgMzgs IGZpcnN0IHBhcmFncmFwaCBhZnRlciBUYWJsZSA1LiAgT3JwaGFuZWQgc2VudGVuY2U6ICAKICAg ICAgICAgICAgIlRoZSBESENQUkVRVUVTVCBtZXNzYWdlIGNvbnRhaW5zIHRoZSBzYW1lICd4aWQn IGFzIHRoZSAKICAgICAgICAgICAgREhDUE9GRkVSIG1lc3NhZ2UuIiAgTm8gaXQgZG9lc24ndC4g IE5vdCBvbmx5IHRoYXQsIGJ1dCB0aGlzIAogICAgICAgICAgICBzZW50ZW5jZSBtYWtlcyBubyBz ZW5zZSBpbiBpdHMgY3VycmVudCBsb2NhdGlvbi4gIEl0IHNob3VsZCBiZSAKICAgICAgICAgICAg cmVtb3ZlZC4gCgogICAgICAgIDcuICBQYWdlIDM5LCBMYXN0IHBhcmFncmFwaCBvZiA0LjQuMyBz aG91bGQgYmUgbW92ZWQgdXAgYXMgdGhlIAogICAgICAgICAgICBsYXN0IHBhcmFncmFwaCBvZiA0 LjQuMi4gIFdoZW4gdGhlIHRleHQgZm9yIERIQ1BJTkZPUk0gd2FzIAogICAgICAgICAgICBhZGRl ZCwgdGhlIHRleHQgZGVzY3JpYmluZyB3aGF0IGEgY2xpZW50IHNob3VsZCBkbyBpZiBubyAKICAg ICAgICAgICAgREhDUEFDSyBpcyByZWNlaXZlZCB3YXMgbWlzdGFrZW5seSBwdXNoZWQgYmVsb3cg aXQuIAoKICAgICAgICA4LiAgQXBvc3Ryb3BoZXMgKCcpIGFyZSB1c2VkIGFzIHNpbmdsZSBxdW90 YXRpb24gbWFya3MsIGJ1dCAKICAgICAgICAgICAgb3V0c2lkZSBvZiBhbiBlbmNsb3NpbmcgcXVv dGF0aW9uICgiKSB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4gCgoKCiAgICAgIAogICAgIEhpYmJz ICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAgICAgICBb UGFnZSA0XSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1w bGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAgICAgOS4g IFBhZ2UgMzAsIHNlY3Rpb24gNC4zLjEsIHNlY29uZCBmcm9tIGxhc3QgYnVsbGV0OiAiLi4uY2xp ZW50knMgCiAgICAgICAgICAgIHZlbmRvciBjbGFzcyBpZGVudGlmaWVyIGFuZCBjbGllbnQncyBj bGFzc2VzIGlkZW50aWZpZWQgaW4gdGhlIAogICAgICAgICAgICBzZXJ2ZXIiLiAgVGhpcyB0ZXh0 IG1ha2VzIG5vIHNlbnNlIGFuZCBzaG91bGQgYmUgZGVsZXRlZC4gCgogICAgICAgIDEwLiBJbmNv bnNpc3RlbnQgc3R5bGUgcmVnYXJkaW5nIHBsYWNlbWVudCBvZiBwZXJpb2RzICguKSwgY29tbWFz IAogICAgICAgICAgICAoLCkgYW5kIHNlbWktY29sb25zICg7KSB3aXRoIHJlc3BlY3QgdG8gcXVv dGF0aW9uIG1hcmtzIAogICAgICAgICAgICB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4gCgogICAg ICAgIDExLiBRdW90YXRpb24gbWFya3MgKHNpbmdsZSBhbmQgZG91YmxlKSBhcmUgb3ZlcnVzZWQg dGhyb3VnaCB0aGUgCiAgICAgICAgICAgIGRvY3VtZW50LiAKCgogICAgIDIuMi4zLiBPbWlzc2lv bnMgCgogICAgICAgIEluIHNldmVyYWwgcGxhY2VzIHRoZXJlIGlzIG1pc3Npbmcgb3IgaW5jb21w bGV0ZSBpbmZvcm1hdGlvbiwgCiAgICAgICAgaW5jbHVkaW5nOiAKCiAgICAgICAgMS4gIFRhYmxl IDMsIHBhZ2VzIDI3IGFuZCAyOC4gLiAgVGhlICJvcHRpb25zIiBlbnRyeSBmb3IgIkRIQ1BOQUsi IAogICAgICAgICAgICBpbiB0aGUgImZpZWxkcyIgcG9ydGlvbiBvZiB0aGUgdGFibGUgaXMgbWlz c2luZy4gIEFsbCBlbnRyaWVzIAogICAgICAgICAgICBpbiB0aGlzIGxpbmUgc2hvdWxkIHJlZmVy IHRvIHRoZSBzdWJzZXF1ZW50ICJvcHRpb25zIiB0YWJsZS4gCgogICAgICAgIDIuICBQYWdlIDMz LCBUYWJsZSA0LCBhbmQgUGFnZSAzNSwgRmlndXJlIDUsIGRvIG5vdCBpbmNsdWRlIHRoZSAKICAg ICAgICAgICAgIkRIQ1BJTkZPUk0iIG1lc3NhZ2UuIAoKICAgICAgICAzLiAgVGFibGUgNSwgcGFn ZXMgMzcgYW5kIDM4LiAgVGhlICJvcHRpb25zIiBlbnRyeSBmb3IgCiAgICAgICAgICAgICJESENQ REVDTElORSwgREhDUFJFTEVBU0UiIGlzIG1pc3NpbmcuICBBbGwgZW50cmllcyBpbiB0aGlzIAog ICAgICAgICAgICBsaW5lIHNob3VsZCByZWZlciB0byB0aGUgc3Vic2VxdWVudCB0YWJsZS4gCgoK ICAgICAyLjIuNC4gVGFibGVzIAoKICAgICAgICAxLiAgVGFibGUgMyAocGFnZXMgMjggYW5kIDI5 KSBhbmQgVGFibGUgNSAocGFnZXMgMzcgYW5kIDM4KSBzaG91bGQgCiAgICAgICAgICAgIGJlIHNl cGFyYXRlZCBpbnRvIHR3byB0YWJsZXMgZWFjaCBmb3IgcmVhZGFiaWxpdHkuIAoKICAgICAgICAy LiAgVGFibGUgNCBzaG91bGQgYmUgcmVvcmdhbml6ZWQgdG8gc2hvdyBhbGwgbWVzc2FnZXMgKGV4 Y2VwdCAKICAgICAgICAgICAgREhDUFJFTEVBU0UpIHRoYXQgYXJlIHNlbnQgZnJvbSBlYWNoIGNs aWVudCBzdGF0ZS4gCgogICAgICAgIDMuICBUaGUgIkhvc3QgQ29uZmlndXJhdGlvbiBQYXJhbWV0 ZXJzIiB0YWJsZSBub3cgaW4gYW4gYXBwZW5kaXggCiAgICAgICAgICAgIHNob3VsZCBiZSBvbWl0 dGVkIGFuZCBkZXNjcmliZWQgaW4gYSByZXZpc2VkICJESENQIE9wdGlvbnMiIAogICAgICAgICAg ICBkb2N1bWVudCAoUkZDIDIxMzIpLiAKCgogICAgIDIuMi41LiBJbmNvbnNpc3RlbmNpZXMgCgog ICAgICAgIDEuICBQYWdlIDEsIEFic3RyYWN0LCAiVENQSVAiIHNob3VsZCBiZSAiVENQL0lQIiCW IGFzIGl0IGlzIGluIHRoZSAKICAgICAgICAgICAgcmVzdCBvZiB0aGUgZG9jdW1lbnQuIAoKICAg ICAgICAyLiAgUGFnZSAxMCwgVGFibGUgMywgZGVzY3JpcHRpb24gb2YgJ2h0eXBlJyBhbmQgJ2hs ZW4nIGZpZWxkcyBkb2VzIAogICAgICAgICAgICBub3QgY2FwaXRhbGl6ZSAiRXRoZXJuZXQuIiAK CiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAzICsgNiBt b250aHMgICAgICAgICAgICBbUGFnZSA1XSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0IERyYWZ0 ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIgMjAwMyAK ICAgICAgCiAgICAgICAgMy4gIExhY2sgb2YgY29uc2lzdGVuY3kgd2hlbiBkZXNjcmliaW5nICJJ UCBicm9hZGNhc3QuIiAgU29tZXRpbWVzIGl0IAogICAgICAgICAgICBpcyAiMHhmZmZmZmZmZiBJ UCBicm9hZGNhc3QsIiBlbHNld2hlcmUgImxpbWl0ZWQgYnJvYWRjYXN0LCIgb3IgCiAgICAgICAg ICAgICJicm9hZGNhc3QuIiAgU3VnZ2VzdCB1c2luZyB0aGUgIjI1NS4yNTUuMjU1LjI1NSBJUCBi cm9hZGNhc3QgCiAgICAgICAgICAgIGFkZHJlc3MiIGZvcm0sIGFzIHRoYXQgaXMgdGhlIG1vc3Qg c3BlY2lmaWMuICBTcGVjaWZpYyByZWZlcmVuY2VzIAogICAgICAgICAgICBpbmNsdWRlOiAKCiAg ICAgICAgICAgICAgIFBhZ2UgMTksIHRoaXJkIHBhcmFncmFwaCBvZiBzZWN0aW9uIDMuMiwgTGlz dCBpdGVtICMyIAoKICAgICAgICAgICAgICAgUGFnZSAyMywgZmlmdGggcGFyYWdyYXBoIG9mIHNl Y3Rpb24gNC4xICh0d2ljZSkgCgogICAgICAgICAgICAgICBQYWdlIDI1LCB0aGlydGVlbnRoIHBh cmFncmFwaCBvZiBzZWN0aW9uIDQuMSAodHdpY2UpIAoKICAgICAgICAgICAgICAgUGFnZSAzMiwg c2VjdGlvbiA0LjMuMiwgdGhpcmQgYnVsbGV0IGl0ZW0gCgogICAgICAgICAgICAgICBQYWdlIDMy LCBzZWN0aW9uIDQuMy4yLCBmaWZ0aCBidWxsZXQgaXRlbSAKCiAgICAgICAgICAgICAgIFBhZ2Ug MzYsIHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0LjQuMSAKCiAgICAgICAgICAgICAgIFBh Z2UgMzksIGxhc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC40LjEgCgogICAgICAgICAgICAgICBQ YWdlIDM5LCBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC40LjMgCgogICAgICAgIDQuICBM YWNrIG9mIGNvbnNpc3RlbmN5IHdoZW4gcmVmZXJyaW5nIHRvIHRoZSBCUk9BRENBU1QgKEIpIGZs YWc6ICBpdCAKICAgICAgICAgICAgaXMgYWxzbyByZWZlcnJlZCB0byBhcyB0aGUgImJyb2FkY2Fz dCBiaXQuIiAKCiAgICAgICAgNS4gIFRhYmxlIDMsICJGaWVsZHMgYW5kIG9wdGlvbnMgdXNlZCBi eSBESENQIHNlcnZlcnMsIiBpcyAKICAgICAgICAgICAgcHJvYmxlbWF0aWMuICBJdCBpbmRpY2F0 ZXMgdGhhdCB3ZSBNVVNUIGZpbGwgaW4gYm90aCB0aGUgIlNlcnZlciAKICAgICAgICAgICAgSWRl bnRpZmllciIgKGFuZCBzaWFkZHIpIGluIG91ciBESENQQUNLIChhbmQgREhDUE5BSykgcmVzcG9u c2UuICAKICAgICAgICAgICAgVGhhdCdzIGEgY2hhbmdlIGZyb20gdGhlIHNhbWUgdGFibGUgaW4g UkZDIDE1NDEgdGhhdCBzcGVjaWZpZXMgCiAgICAgICAgICAgIHRoaXMgaXMgYSAiTUFZIiAoYW5k IHdoaWNoIGlzIGNvbnNpc3RlbnQgd2l0aCBSRkMgMjEzMiBzZWN0aW9uIAogICAgICAgICAgICA5 LjcgYW5kIGlkZW50aWNhbCBSRkMgMTUzMyBzZWN0aW9uIDkuNSB3b3JkaW5nKS4gCgoKICAgICAy LjMuIFBvbGljeSBpc3N1ZXMgCgogICAgICAgIFRoZXJlIGhhcyBpbiBnZW5lcmFsIGJlZW4gYSBj ZXJ0YWluIGFtb3VudCBvZiBvdmVybGFwIGluIERIQ1AgYmV0d2VlbiAKICAgICAgICBwcm90b2Nv bCBhbmQgcG9saWN5LiAgVGhlIG1hdHRlcnMgaW5jbHVkZSBsZWFzZSB0aW1lcywgd2hldGhlciAK ICAgICAgICBzZXJ2ZXJzIGFyZSB3aWxsaW5nIHRvIGV4dGVuZCBsZWFzZXMsIHRpbWVvdXRzLCBh bmQgcmUtdHJhbnNtaXNzaW9uLiAKCiAgICAgICAgV2UgU0hPVUxEIGNsYXJpZnkgd2hhdCBpcyBk aWN0YXRlZCBieSB0aGUgcHJvdG9jb2wgYW5kIHdoYXQgaXMgYSAKICAgICAgICBwb2xpY3kgZGVj aXNpb24gYXQgYSBnaXZlbiBzaXRlLiAKCiAgICAgICAgVGhlIERIQyBXb3JraW5nIEdyb3VwIHBo aWxvc29waHkgb3VnaHQgdG8gYmUgdG8gY29uc3RyYWluIGNsaWVudCAKICAgICAgICBiZWhhdmlv ciBtb3JlIGNsb3NlbHkgdGhhbiBzZXJ2ZXIgYmVoYXZpb3IuICBESENQIGludGVyYWN0aW9ucyBh cmUgCiAgICAgICAgaW5pdGlhdGVkIChhbmQgY29udGludWVkKSBieSBjbGllbnRzOiAgY2xpZW50 cyBvdXRudW1iZXIgc2VydmVycyBieSAKICAgICAgICBtYW55IHRlbnMgb2YgdGhvdXNhbmRzIHRv IG9uZTsgY2xpZW50IGltcGxlbWVudGVycyBjYW5ub3QgYmUgcXVpdGUgCiAgICAgICAgY2VydGFp biBvZiBhbGwgdGhlIGVudmlyb25tZW50cyBpbiB3aGljaCB0aGVpciBjbGllbnQgbWF5IHVsdGlt YXRlbHkgCiAgICAgICAgYXBwZWFyLCB3aGVyZWFzIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgbWF5 IGJlIGRlc2lnbmVkIGZvciB2ZXJ5IAogICAgICAgIHNwZWNpZmljIGVudmlyb25tZW50cy4gIFBv bGljeSBpcyBsaWtlbHkgdG8gYmUgYSBtYXR0ZXIgb2YgCgogICAgICAKICAgICBIaWJicyAgICAg ICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICAgW1BhZ2Ug Nl0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMxIEltcGxlbWVu dGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAgICAgIGNlbnRyYWxp emVkIGNvbnRyb2wsIHdoZXJlYXMgY2xpZW50cyBhcmUgbm90IGxpa2VseSB0byBlbmpveSBhIAog ICAgICAgIHN1ZmZpY2llbnQgc3RhdHVzIHRvIGltcG9zZSBwb2xpY3kgb24gc2VydmVycy4gCgog ICAgICAgIFRoZSBwcmV2aW91cyBwYXJhZ3JhcGggaW1wbGllcyB0aGF0IHRoZSBXT1JLSU5HIEdS T1VQIHNob3VsZCB0aWdodGVuIAogICAgICAgIHRoZSBwcm90b2NvbCB3aXRoIHJlc3BlY3QgdG8g c3VjaCBpc3N1ZXMgYXMgcmV0cmllcyBhbmQgYmFja29mZnMsIAogICAgICAgIHdoZXJlYXMgc2Vy dmVycyBzaG91bGQgbm90IGJlIGNvbnN0cmFpbmVkIG9uIGlzc3VlcyBzdWNoIGFzIGhvdyB0byAK ICAgICAgICB1bmlxdWVseSBpZGVudGlmeSBjbGllbnRzLCB3aGV0aGVyIHRvIG9mZmVyIG9yIGV4 dGVuZCBsZWFzZXMgZXRjLiAKCgogICAgIDIuNC4gVGhlIENsaWVudCBIYXJkd2FyZSBBZGRyZXNz LCAiY2hhZGRyIiAKCiAgICAgICAgVGhlIHZhbHVlIG9mICJjaGFkZHIiIE1VU1QgTk9UIGNoYW5n ZSBmcm9tIERIQ1BESVNDT1ZFUiB0byAKICAgICAgICBESENQUkVRVUVTVCwgYWx0aG91Z2ggdGhl IHdvcmRpbmcgaW4gdGFibGUgMyBtYWtlcyB0aGlzIHBvaW50IAogICAgICAgIHVuY2xlYXIuIAoK ICAgICAgICBGdXJ0aGVyLCB0aGUgbGVuZ3RoIG9mICJjaGFkZHIiIFNIT1VMRCBiZSBleGFjdGx5 IHNwZWNpZmllZCBieSAKICAgICAgICAiaGxlbiwiIHdoaWNoIFNIT1VMRCBtYXRjaCB0aGUgYWRk cmVzcyBsZW5ndGggZm9yICJodHlwZS4iIAoKCiAgICAgMi41LiBUaGUgREhDUCBDbGllbnQgSWRl bnRpZmllciAKCgogICAgIDIuNS4xLiBVbmlxdWVuZXNzIAoKICAgICAgICBESENQIHNlcnZlcnMg bXVzdCB1bmlxdWVseSBpZGVudGlmeSBESENQIGNsaWVudHMgcmVxdWVzdGluZyBzZXJ2aWNlcyAK ICAgICAgICBpbiBvcmRlciB0byBjb3JyZWN0bHkgY29uZmlndXJlIHRoZSBjbGllbnQuICBSRkMg MjEzMSBwcm92aWRlcyB0d28gCiAgICAgICAgc3BlY2lmaWMgbWV0aG9kcyBmb3IgaWRlbnRpZnlp bmcgYSBjbGllbnQ6ICAoMSkgdGhlIGNsaWVudCBpZGVudGlmaWVyIAogICAgICAgIChESENQIE9w dGlvbiA2MSkgW1JGQzIxMzJdLCBhbmQgKDIpIHRoZSAiY2hhZGRyIiBmaWVsZCBvZiB0aGUgCiAg ICAgICAgQk9PVFBSRVFVRVNUIHBhY2tldC4gCgogICAgICAgIENvbmZ1c2lvbiBhcmlzZXMgZnJv bSB0aGUgbGFuZ3VhZ2Ugb2YgUkZDIDIxMzEgU2VjdGlvbiA0LjIuICBBIERIQ1AgCiAgICAgICAg Y2xpZW50ICIuLi5NQVkgY2hvb3NlIHRvIGV4cGxpY2l0bHkgcHJvdmlkZSB0aGUgaWRlbnRpZmll ciB0aHJvdWdoIAogICAgICAgIHRoZSAnY2xpZW50IGlkZW50aWZpZXInIG9wdGlvbi4gIElmIHRo ZSBjbGllbnQgc3VwcGxpZXMgYSAnY2xpZW50IAogICAgICAgIGlkZW50aWZpZXIsJyB0aGUgY2xp ZW50IE1VU1QgdXNlIHRoYXQgc2FtZSBpZGVudGlmaWVyIGluIGFsbCAKICAgICAgICBzdWJzZXF1 ZW50IG1lc3NhZ2VzLCBhbmQgdGhlIHNlcnZlciBNVVNUIHVzZSB0aGF0IGlkZW50aWZpZXIgdG8g CiAgICAgICAgaWRlbnRpZnkgdGhlIGNsaWVudC4gIElmIHRoZSBjbGllbnQgZG9lcyBub3QgcHJv dmlkZSBhICdjbGllbnQgCiAgICAgICAgaWRlbnRpZmllcicgb3B0aW9uLCB0aGUgc2VydmVyIE1V U1QgdXNlIHRoZSBjb250ZW50cyBvZiB0aGUgJ2NoYWRkcicgCiAgICAgICAgZmllbGQgdG8gaWRl bnRpZnkgdGhlIGNsaWVudC4iIAoKICAgICAgICBUaGUgdGV4dCBvZiB0aGUgcXVvdGVkIHNlY3Rp b24gZ29lcyBvbiB0byBzdGF0ZSB0aGF0IHN1Ym5ldCAKICAgICAgICB1bmlxdWVuZXNzIGlzIGEg cmVxdWlyZW1lbnQgZm9yIGFuIGlkZW50aWZpZXIsIGJ1dCBwb2ludHMgb3V0IHRoYXQgCiAgICAg ICAgImNoYWRkciIgbWF5IG5vdCBzYXRpc2Z5IHRoYXQgcmVxdWlyZW1lbnQuICBUd28gYWx0ZXJu YXRpdmVzIGZvciBhIAogICAgICAgIHVuaXF1ZSBpZGVudGlmaWVyIHdlcmUgZ2l2ZW46IGFuIHVu c3BlY2lmaWVkIG1hbnVmYWN0dXJlcidzIHNlcmlhbCAKICAgICAgICBudW1iZXIgb3IgYSBETlMg bmFtZS4gCgogICAgICAgIFJGQyAyMTMyIGFkZHMgdG8gdGhlIGNvbmZ1c2lvbiBieSBzdGF0aW5n IHRoYXQgdGhlIGNsaWVudCBpZGVudGlmaWVyIAogICAgICAgICIuLi5pcyBleHBlY3RlZCB0byBi ZSB1bmlxdWUgZm9yIGFsbCBjbGllbnRzIGluIGFuIGFkbWluaXN0cmF0aXZlIAogICAgICAgIGRv bWFpbiIgd2l0aG91dCBzcGVjaWZ5aW5nIHdoYXQgYW4gImFkbWluaXN0cmF0aXZlIGRvbWFpbiIg aXMuIAoKCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAz ICsgNiBtb250aHMgICAgICAgICAgICBbUGFnZSA3XSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0 IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIg MjAwMyAKICAgICAgCiAgICAgICAgUkZDIDIxMzIgY29udGludWVzIGJ5IHN1Z2dlc3RpbmcgdXNl IG9mICIuLi50eXBlLXZhbHVlIHBhaXJzIHNpbWlsYXIgCiAgICAgICAgdG8gdGhlICdodHlwZScv J2NoYWRkcicgZmllbGRzIGRlZmluZWQgaW4iIFtSRkM5NTFdLCBhbmQgdGhhdCBhIAogICAgICAg ICIuLi5oYXJkd2FyZSB0eXBlIG9mIDAgKHplcm8pIHNob3VsZCBiZSB1c2VkIHdoZW4gdGhlIHZh bHVlIGZpZWxkIAogICAgICAgIGNvbnRhaW5zIGFuIGlkZW50aWZpZXIgb3RoZXIgdGhhbiBhIGhh cmR3YXJlIGFkZHJlc3MgKGUuZy4sIGEgZnVsbHkgCiAgICAgICAgcXVhbGlmaWVkIGRvbWFpbiBu YW1lKS4iIAoKICAgICAgICBUaGlzIHN1Z2dlc3Rpb24gb2YgdXNpbmcgdHlwZS12YWx1ZSBwYWly cyBoYXMgYmVlbiB3aWRlbHkgYWRvcHRlZCBieSAKICAgICAgICBESENQIGNsaWVudCBpbXBsZW1l bnRlcnMsIGJ1dCB0aGUgc3VnZ2VzdGlvbiBmYWlscyB0byBoZWVkIHRoZSAKICAgICAgICB3YXJu aW5nIGFib3V0IHVuaXF1ZW5lc3MgaXNzdWVzIHdpdGggImNoYWRkci4iIAoKICAgICAgICBSRUNP TU1FTkRBVElPTlM6IAoKICAgICAgICBvICBSRkMgMjEzMSBTSE9VTEQgaGF2ZSBtYWRlIHJlcXVp cmVkIHRoZSAiY2xpZW50IGlkZW50aWZpZXIiIAogICAgICAgICAgIGVpdGhlciB0byBiZSBnbG9i YWxseSB1bmlxdWUgb3IsIHRvIGJlIHVuaXF1ZSB3aXRoaW4gYW4gCiAgICAgICAgICAgImFkbWlu aXN0cmF0aXZlIGRvbWFpbiwiIGFuZCwgaW4gdGhlIGxhdHRlciBjYXNlLCBkZWZpbmVkIAogICAg ICAgICAgICJhZG1pbmlzdHJhdGl2ZSBkb21haW4uIiAKCiAgICAgICAgbyAgUkZDIDIxMzEgU0hP VUxEIE5PVCBoYXZlIHN1Z2dlc3RlZCB0aGUgdXNlIG9mIEROUyBuYW1lcyBmb3IgdGhlIAogICAg ICAgICAgICJjbGllbnQgaWRlbnRpZmllciIgd2l0aG91dCBhbHNvIHN1Z2dlc3Rpbmcgc29tZSBt ZWNoYW5pc20gZm9yIAogICAgICAgICAgIG1haW50YWluaW5nIGEgY29uc2lzdGVudCBuYW1lLXRv LWFkZHJlc3MgbWFwcGluZy4gCgogICAgICAgIG8gIFJGQyAyMTMyIFNIT1VMRCBOT1QgaGF2ZSBz dWdnZXN0ZWQgdXNpbmcgdGhlICJodHlwZSIgYW5kIAogICAgICAgICAgICJjaGFkZHIiIGZpZWxk cyBhcyBhIHR5cGUtdmFsdWUgcGFpciBiZWNhdXNlIG9mIHRoZSB3YXJuaW5nIGluIAogICAgICAg ICAgIFJGQyAyMTMxIFNlY3Rpb24gNC4yIGFib3V0IHBvdGVudGlhbCBwcm9ibGVtcyB1c2luZyAi Y2hhZGRyIiAKICAgICAgICAgICBmb3IgdGhlIHB1cnBvc2UuIAoKICAgICAgICBvICBSRkMgMjEz MiBTSE9VTEQgTk9UIGhhdmUgdXNlZCB0aGUgd29yZCAiU0hPVUxEIiB3aGVuIHN1Z2dlc3Rpbmcg CiAgICAgICAgICAgdGhlIHVzZSBvZiB0eXBlLXZhbHVlIHBhaXJzIGZvciAiY2xpZW50IGlkZW50 aWZpZXIiIHdpdGggYSB0eXBlIAogICAgICAgICAgIG9mIDAgKHplcm8pIHdoZW4gdGhlIHZhbHVl IGlzIGFueXRoaW5nIG90aGVyIHRoYW4gYSBoYXJkd2FyZSAKICAgICAgICAgICBhZGRyZXNzLiAK CgogICAgIDIuNS4yLiBQcm9oaWJpdGlvbiBpbiBESENQT0ZGRVIgYW5kIERIQ1BBQ0sgCgogICAg ICAgIFRhYmxlIDMsIGluIHRoZSAib3B0aW9ucyIgc2VjdGlvbiwgc3BlY2lmaWVzIHRoYXQgdGhl IHNlcnZlciBNVVNUIE5PVCAKICAgICAgICBzZW5kIHRoZSAiY2xpZW50IGlkZW50aWZpZXIiIGlu IHRoZSBESENQT0ZGRVIgb3IgREhDUEFDSyBtZXNzYWdlcywgCiAgICAgICAgYnV0IE1BWSBzZW5k IGl0IGluIGEgREhDUE5BSyBtZXNzYWdlLiAgVGhlcmUgaXMgbm8gdmVyeSBnb29kIHJlYXNvbiAK ICAgICAgICB3aHkgREhDUE5BSyBzaG91bGQgYmUgdHJlYXRlZCBkaWZmZXJlbnRseSwgYW5kIHRo ZXJlIGlzIGNvbnNpZGVyYWJsZSAKICAgICAgICB1dGlsaXR5IGluIHJldHVybmluZyB0aGUgY2xp ZW50IGlkZW50aWZpZXIsIGFzIGl0IGFsbG93cyBjbGllbnRzIAogICAgICAgIGZ1cnRoZXIgY29y cm9ib3JhdGlvbiwgYmV5b25kIHRoYXQgaW1wbGllZCBieSBtYXRjaGluZyAieGlkknMiIChzZWUg CiAgICAgICAgMi4yMyksIHRoYXQgdGhleSBhcmUgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gCgog ICAgICAgIFJFQ09NTUVOREFUSU9OUzogCgogICAgICAgIENoYW5nZSB0aGUgdGV4dCBpbiBUYWJs ZSAzLCBmb3IgYWxsIHRocmVlIG1lc3NhZ2UgdHlwZXMsIHRvIHJlYWQ6IAogICAgICAgICJNQVkg LS0gaWYgaW5jbHVkZWQsIE1VU1QgQkUgdGhlIGNsaWVudCBpZGVudGlmaWVyIHNlbnQgYnkgdGhl IAogICAgICAgIGNsaWVudCIuIAoKCgogICAgICAKICAgICBIaWJicyAgICAgICAgICAgICAgICBF eHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICAgW1BhZ2UgOF0gCgoKCgoKCgoK CgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3Vl cyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAgIDIuNi4gQWRkcmVzcy1pbi1Vc2UgRGV0 ZWN0aW9uIAoKICAgICAgICBSRkMgMjEzMSBQYWdlIDcsIHNlY3Rpb24gMS42LCBzZWNvbmQgc2V0 IG9mIGJ1bGxldCBpdGVtcywgZmlyc3QgCiAgICAgICAgYnVsbGV0IHNheXMgdGhhdCBESENQIG11 c3Q6ICJHdWFyYW50ZWUgdGhhdCBhbnkgc3BlY2lmaWMgbmV0d29yayAKICAgICAgICBhZGRyZXNz IHdpbGwgbm90IGJlIGluIHVzZSBieSBtb3JlIHRoYW4gb25lIGNsaWVudCBhdCBhIHRpbWUsIiBi dXQgCiAgICAgICAgdGhlIHByb3RvY29sIGFzIGxhdGVyIGRlc2NyaWJlZCBkb2VzIG5vdCBmdWxm aWxsIHRoaXMgcmVxdWlyZW1lbnQuIAoKICAgICAgICBUd28gbWVjaGFuaXNtcyBhcmUgcHJlc2Vu dGVkOiBhbiBBUlAgcmVxdWVzdCBnZW5lcmF0ZWQgYnkgdGhlIGNsaWVudDsgCiAgICAgICAgYW5k IGFuIElDTVAgZWNobyByZXF1ZXN0IGdlbmVyYXRlZCBieSB0aGUgc2VydmVyOiAKCiAgICAgICAg byAgUGFnZSAxMiwgc2Vjb25kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDIuMiwgbGFzdCBzZW50ZW5j ZSAKCiAgICAgICAgbyAgUGFnZSAxMywgbGlzdCBpdGVtIDIsIHNlY3Rpb24gMy4xIAoKICAgICAg ICBvICBQYWdlIDM4LCBmaXJzdCBwYXJhZ3JhcGggYWZ0ZXIgVGFibGUgNSwgc2VjdGlvbiA0LjQu MSAKCgogICAgIDIuNi4xLiBDbGllbnQtc2lkZSBBUlAgCgogICAgICAgIFRvIG1lZXQgdGhlIHJl cXVpcmVtZW50IG9mIFJGQyAyMTMxIHBhZ2UgNywgYSBESENQIGNsaWVudCBNVVNUIHNlbmQgCiAg ICAgICAgYW4gQVJQIHJlcXVlc3QgZm9yIHRoZSBJUCBhZGRyZXNzIGNvbnRhaW5lZCBpbiBhIERI Q1BBQ0sgYmVmb3JlIHVzaW5nIAogICAgICAgIGl0LiAgVGhpcyBpcyBwcmVzZW50bHkgYSBTSE9V TEQ6IAoKICAgICAgICBvICBQYWdlIDEyLCBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMi4y OiAgIi4uLiAgYW5kIHRoZSBjbGllbnQgCiAgICAgICAgICAgU0hPVUxEIHByb2JlIHRoZSBuZXds eSByZWNlaXZlZCBhZGRyZXNzLCBlLmcuLCB3aXRoIEFSUCIgCgogICAgICAgIFRoZXJlIGhhcyBi ZWVuIGNvbmZ1c2lvbiBvbiB0aGlzIHRvcGljIGJlY2F1c2UgbWFueSBjbGllbnRzIGFyZSAKICAg ICAgICBzZW5kaW5nIGFuIEFSUCByZXBseSAoYWZ0ZXIgdGhlIERIQ1BBQ0spLiAgVGhpcyBvZnRl biBoYXMgbm90aGluZyB0byAKICAgICAgICBkbyB3aXRoIERIQ1AsIGFuZCBpcyB0cmlnZ2VyZWQg aW4gbWFueSBzeXN0ZW1zIHdoZW5ldmVyIGFuIGludGVyZmFjZSAKICAgICAgICBJUCBhZGRyZXNz IGNoYW5nZXMuICAoV2l0aG91dCBhY2Nlc3MgdG8ga2VybmVsIGNvZGUgdGhlcmUgaXMgbm90aGlu ZyAKICAgICAgICBvbmUgY2FuIGRvIGFib3V0IGl0LikgCgogICAgICAgIFJFQ09NTUVOREFUSU9O UzogCgogICAgICAgIG8gIFRoZSBXb3JraW5nIEdyb3VwIHNob3VsZCBjb25zaWRlciB3aGV0aGVy IHRvIG1ha2UgY2xpZW50IEFSUCBhIAogICAgICAgICAgIE1VU1QuIAoKCiAgICAgMi42LjIuIFNl cnZlciBzaWRlIFBJTkcuIAoKICAgICAgICBJQ01QIGlzIGluaGVyZW50bHkgdW5yZWxpYWJsZS4g IEZ1cnRoZXJtb3JlIHNpbmNlIHN1Y2Nlc3MgaXMgIm5vIAogICAgICAgIHJlc3BvbnNlIiBpdCBp cyBhbiBpbXByZWNpc2UgbWF0dGVyIHRvIGRlY2lkZSBob3cgbG9uZyB0byB3YWl0IGJlZm9yZSAK ICAgICAgICBvbmUgaXMgY2VydGFpbiB0aGF0IG5vIHJlc3BvbnNlIHdpbGwgZXZlciBvY2N1ci4g IEEgcG9zc2libGUgCiAgICAgICAgc3VnZ2VzdGlvbiBpcyBhIGJhY2sgb2ZmIGFuZCByZXRyeSBm b3IgcGluZy4gCgogICAgICAgIEluIGNhYmxlIG1vZGVtIGVudmlyb25tZW50cywgUElORyBpcyBu b3QgaGVscGZ1bCBiZWNhdXNlIGl0IGlzIHRoZSAKICAgICAgICBjYWJsZSBtb2RlbSB0ZXJtaW5h dGlvbiBzeXN0ZW0gKENNVFMpIHRoYXQgcmVwbGllcyBmcm9tIGl0cyBjYWNoZTogIGEgCiAgICAg ICAgY2FjaGUgd2hpY2ggbWF5IG5vdCBiZSBwZXJmZWN0bHkgcmVsaWFibGUgYW5kIHdoaWNoIGlu IG1hbnkgY2FzZXMgaGFzIAogICAgICAgIGJlZW4gY29uc3RydWN0ZWQgYnkgbGlzdGVuaW5nIHRv IHRoZSBESENQIHRyYWZmaWMgaW4gdGhlIGZpcnN0IHBsYWNlISAKCiAgICAgIAogICAgIEhpYmJz ICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAgICAgICBb UGFnZSA5XSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1w bGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAgICAgSXQg aXMga25vd24gdGhhdCBzb21lIG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdHJ5IHRvIGJsb2NrIHBy b3BhZ2F0aW9uIAogICAgICAgIG9mIElDTVAgRUNITyBtZXNzYWdlcyB0aHJvdWdoIGludGVybmFs IHJvdXRlcnMsIHdoaWNoIHJlbW92ZXMgb25lIG9mIAogICAgICAgIHRoZSB0d28gYWRkcmVzcyBj b25mbGljdCBkZXRlY3Rpb24gbWVjaGFuaXNtcy4gCgogICAgICAgIFJFQ09NTUVOREFUSU9OUzog CgogICAgICAgIG8gIFVzZSBvZiBJQ01QIG9uIHRoZSBzZXJ2ZXIgc2hvdWxkIGJlIGEgk01BWZQs IG5vdCBhIJNTSE9VTESULiAKCgogICAgIDIuNi4zLiBPdGhlciBNZWNoYW5pc21zIAoKICAgICAg ICBCb3RoIHRoZSBJQ01QIEVDSE8gKFBpbmcpIGFuZCBBZGRyZXNzIFJlc29sdXRpb24gUHJvdG9j b2wgKEFSUCkgCiAgICAgICAgbWVjaGFuaXNtcyBhcmUgdmVyeSBsaWdodHdlaWdodCBieSBkZXNp Z24sIGRlcGVuZGluZyBvbiBjbGllbnRzIHdpdGggCiAgICAgICAgY29uZmxpY3RpbmcgYWRkcmVz c2VzIHRvICJkZWZlbmQiIHRoZWlyIGFkZHJlc3MgYnkgcmVzcG9uZGluZyB0byAKICAgICAgICBx dWVyaWVzIHRvIHNob3cgdGhhdCBhbiBhZGRyZXNzIGlzIGluIHVzZS4gIElzIHRoZXJlIGEgYmV0 dGVyIAogICAgICAgIGFsdGVybmF0aXZlIHRvIElDTVAgRUNITyBhbmQgQVJQIHRoYXQgaXMgYmFj a3dhcmQtY29tcGF0aWJsZSB3aXRoIAogICAgICAgIHRoZXNlIHR3byBwcm90b2NvbHM/IAoKCiAg ICAgMi43LiBESENQIFJlbGF5IEFnZW50cyAKCgogICAgIDIuNy4xLiBSZWxheSBBZ2VudCBTb3Vy Y2UgQWRkcmVzc2VzIAoKICAgICAgICBUaGVyZSBzaG91bGQgYmUgc29tZSB0ZXh0IHRoYXQgc3Bl Y2lmaWVzIHdoYXQgdGhlIHJlbGF5IGFnZW50IHNob3VsZCAKICAgICAgICB1c2UgZm9yIHRoZSBJ UCBzb3VyY2UgYWRkcmVzcyBvZiByZWxheWVkIHBhY2tldHMuICBCZWNhdXNlIHJlbGF5IAogICAg ICAgIGFnZW50cyBjaGFuZ2UgdGhlIHBheWxvYWQgKCJnaWFkZHIiIGFuZCByZWxheSBhZ2VudCBv cHRpb24gODIpIHRoZWlyIAogICAgICAgIG9wZXJhdGlvbiBkb2VzIG5vdCBhbW91bnQgdG8gSVAg Zm9yd2FyZGluZy4gIFRoZSBJUCBzb3VyY2UgYWRkcmVzcyAKICAgICAgICB0aGV5IHVzZSBzaG91 bGQgYmUgdGhlaXIgb3duLiAgW0FzaWRlOiBmb3Igc2VjdXJpdHkgcHVycG9zZXMgaXQgbWlnaHQg CiAgICAgICAgaGF2ZSBiZWVuIGJldHRlciB0aGFuIHRoZXkgcmV0YWluIHRoZSBzb3VyY2UgSVAg YWRkcmVzcyBvZiB0aGUgCiAgICAgICAgb3JpZ2luYWwgcGFja2V0LCBidXQgaXQgaXMgdG9vIGxh dGUgdG8gY2hhbmdlIGFsbCB0aGF0Ll0gCgoKICAgICAyLjcuMi4gUmVsYXkgQWdlbnQgUG9ydCBV c2FnZSAKCiAgICAgICAgUmVsYXkgYWdlbnRzIHNob3VsZCB1c2UgcG9ydCA2NyBhcyB0aGUgc291 cmNlIHBvcnQgbnVtYmVyLiAgUmVsYXkgCiAgICAgICAgYWdlbnRzIGFsd2F5cyBsaXN0ZW4gb24g cG9ydCA2NywgYnV0IHBvcnQgNjggaGFzIHNvbWV0aW1lcyBiZWVuIHVzZWQgCiAgICAgICAgYXMg dGhlIHNvdXJjZSBwb3J0IG51bWJlciBwcm9iYWJseSBiZWNhdXNlIGl0IHdhcyBjb3BpZWQgZnJv bSB0aGUgCiAgICAgICAgc291cmNlIHBvcnQgb2YgdGhlIGluY29taW5nIHBhY2tldC4gCgogICAg ICAgIENhYmxlIG1vZGVtIHZlbmRvcnMgd291bGQgbGlrZSB0byBpbnN0YWxsIGZpbHRlcnMgYmxv Y2tpbmcgb3V0Z29pbmcgCiAgICAgICAgcGFja2V0cyB3aXRoIHNvdXJjZSBwb3J0IDY3LiAKCiAg ICAgICAgUkVDT01NRU5EQVRJT05TOiAKCiAgICAgICAgbyAgUmVsYXkgYWdlbnRzIE1VU1QgdXNl IDY3IGFzIHRoZWlyIHNvdXJjZSBwb3J0IG51bWJlci4gCgogICAgICAgIG8gIFJlbGF5IGFnZW50 cyBNVVNUIE5PVCBmb3J3YXJkIHBhY2tldHMgd2l0aCBub24temVybyBnaWFkZHIgCiAgICAgICAg ICAgdW5sZXNzIHRoZSBzb3VyY2UgcG9ydCBudW1iZXIgb24gdGhlIHBhY2tldCBpcyA2Ny4gCgog ICAgICAKICAgICBIaWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9u dGhzICAgICAgICAgICBbUGFnZSAxMF0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAg ICAgIFJGQyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAg ICAgIAogICAgIDIuOC4gSG9zdCBOYW1lLCBEb21haW4gTmFtZSwgYW5kIEZRRE5zIAoKICAgICAg ICBBIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZSAoRlFETikgY29uc2lzdHMgb2YgdHdvIGNv bmNlcHR1YWwgCiAgICAgICAgcGFydHM6ICB0aGUgaG9zdCBuYW1lIHBvcnRpb24gYW5kIHRoZSBk b21haW4gbmFtZSBwb3J0aW9uLiAgSG9zdCAKICAgICAgICBuYW1lcyBjb25zaXN0IG9mIG9uZSBv ciBtb3JlIG5vbi1udWxsIHBhcnRzIHNlcGFyYXRlZCBieSB0aGUgSVNPIAogICAgICAgIHBlcmlv ZCAoLikgY2hhcmFjdGVyICgic2VwYXJhdG9yIikgd2hpbGUgZG9tYWluIG5hbWVzIGNvbnNpc3Qg b2YgdHdvIAogICAgICAgIG9yIG1vcmUgbm9uLW51bGwgcGFydHMgZGVsaW1pdGVkIGJ5IHRoZSBz ZXBhcmF0b3IsIG9uZSBvZiB3aGljaCBtdXN0IAogICAgICAgIGJlIGEgdmFsaWQgdG9wLWxldmVs IGRvbWFpbiAoVExEKSBuYW1lLiAgREhDUCBvcHRpb25zIGV4aXN0IGZvciAKICAgICAgICBob3N0 bmFtZSAob3B0aW9uIDEyKSBhbmQgZG9tYWluIG5hbWUgKG9wdGlvbiAxNSksIGFuZCBhcmUgcHJv cG9zZWQgCiAgICAgICAgZm9yIEZRRE4gKGRyYWZ0LWlldGYtZGhjLWZxZG4tb3B0aW9uLTA1LnR4 dCkgYnV0IHRoZSBGUUROIG9wdGlvbiBpcyAKICAgICAgICBub3QgcmVxdWlyZWQgdG8gYmUgYSBj b25jYXRlbmF0aW9uIG9mIGhvc3RuYW1lIGFuZCBkb21haW4gbmFtZS4gCgogICAgICAgIFNob3Vs ZCBSRkMgMjEzMSBleHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIGNsaWVudCBGUUROIE1VU1QgYmUg dGhlIAogICAgICAgIGhvc3QgbmFtZSAob3B0aW9uIDEyKSBjb25jYXRlbmF0ZWQgd2l0aCB0aGUg ZG9tYWluIG5hbWUgKG9wdGlvbiAxNSk/IAoKCiAgICAgMi45LiBPdmVybG9hZGluZyBvZiBESENQ UkVRVUVTVCAKCiAgICAgICAgVGhlIGNsaWVudCBzZW5kcyBhIERIQ1BSRVFVRVNUIG1lc3NhZ2Ug ZnJvbSBzZXZlcmFsIGRpZmZlcmVudCBzdGF0ZXM6ICAKICAgICAgICBJTklULCBJTklULVJFQk9P VCwgUkVCSU5ESU5HLCBhbmQgUkVORVdJTkcuICBEaWZmZXJlbnRpYXRpb24gYW1vbmcgCiAgICAg ICAgdGhlIHN0YXRlcyBpcyBkb25lIGFjY29yZGluZyB0byB0aGUgY29udGV4dCBvZiBvdGhlciBt ZXNzYWdlIGZpZWxkcyAKICAgICAgICBhbmQgb3B0aW9uIHZhbHVlcy4gIEF0IHRoaXMgcG9pbnQg dGhlcmUgcHJvYmFibHkgY2FuIGJlIG5vIGNoYW5nZSBpbiAKICAgICAgICB0aGlzIHVzYWdlLCBi dXQgdGhlIGNvbnRlbnQgb2Ygb3RoZXIgbWVzc2FnZSBmaWVsZHMgYW5kIG9wdGlvbiB2YWx1ZXMg CiAgICAgICAgc2hvdWxkIGJlIGNhcmVmdWxseSByZXZpZXdlZCB0byBlbnN1cmUgY29uc2lzdGVu Y3kgIAoKCiAgICAgMi4xMC4gREhDUElORk9STSAKCiAgICAgICAgVGhlIGludGVudCBvZiBESENQ SU5GT1JNIG1lc3NhZ2VzIGlzIHRvIGFsbG93IGNsaWVudHMgdG8gcXVlcnkgCiAgICAgICAgc2Vy dmVycyBmb3IgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBXSEVUSEVSIE9SIE5PVCB0aGVpciBJ UCBhZGRyZXNzIAogICAgICAgIGhhcyBiZWVuIGFzc2lnbmVkIGJ5IERIQ1AuIAoKICAgICAgICBT ZWN0aW9uIDMuNCBQYXJhIDIgUGFnZSAyMSBzdGF0ZXM6ICJUaGUgc2VydmVyIFNIT1VMRCBjaGVj ayB0aGUgCiAgICAgICAgbmV0d29yayBhZGRyZXNzIGluIGEgREhDUElORk9STSBtZXNzYWdlIGZv ciBjb25zaXN0ZW5jeS4iICBXaGF0IHRoZSAKICAgICAgICBzZXJ2ZXIgc2hvdWxkIGJlIGNoZWNr aW5nIGlzIGEgbXlzdGVyeS4gIFBvc3NpYmx5IHRoZSBpbnRlbnQgd2FzIHRoYXQgCiAgICAgICAg c2VydmVycyBzaG91bGQgdmVyaWZ5IHRoYXQgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIGluIHRoZSBw YWNrZXQgaXMgCiAgICAgICAgaWRlbnRpY2FsIHRvIHRoZSAiY2lhZGRyLiIgIFNpbmNlIHRoZSBz ZXJ2ZXIgc2hvdWxkIHJlcGx5IHRvIAogICAgICAgICJjaWFkZHIsIiB0aGlzIGFmZm9yZHMgc29t ZSBtZWFzdXJlIG9mIHNlY3VyaXR5LCBwcmV2ZW50aW5nIHRoaXJkIAogICAgICAgIHBhcnRpZXMg ZnJvbSBkaXNjb3ZlcmluZyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHBlcnRhaW5pbmcgdG8g CiAgICAgICAgb3RoZXIgY2xpZW50cy4gIFdoZXRoZXIgdGhhdCBpcyBkZXNpcmFibGUsIG9yIHdo ZXRoZXIgaW5zdGVhZCAKICAgICAgICBESENQSU5GT1JNIHNob3VsZCBiZSBhdmFpbGFibGUgdG8g dGhpcmQgcGFydGllcywgc3VjaCBhcyBwcm94aWVzLCBoYXMgCiAgICAgICAgbmV2ZXIgYmVlbiBy ZXNvbHZlZC4gCgogICAgICAgIFNlY3Rpb24gNC40LjQgUGFyYSAxLCAiVXNlIG9mIGJyb2FkY2Fz dCBhbmQgdW5pY2FzdCwiIGhpbnRzIHRoYXQgCiAgICAgICAgY2xpZW50cyBtYXkgYmUgYWJsZSB0 byBicm9hZGNhc3QgREhDUElORk9STSBtZXNzYWdlcyB0byBzZXJ2ZXJzOiAiVGhlIAogICAgICAg IERIQ1AgY2xpZW50IGJyb2FkY2FzdHMgREhDUERJU0NPVkVSLCBESENQUkVRVUVTVCBhbmQgREhD UElORk9STSAKICAgICAgICBtZXNzYWdlcywgdW5sZXNzIHRoZSBjbGllbnQga25vd3MgdGhlIGFk ZHJlc3Mgb2YgYSBESENQIHNlcnZlci4iIAoKICAgICAgICBUaGlzIHRleHQgc3VnZ2VzdHMgdGhh dCBhIERIQ1AgY2xpZW50IG1heSBjaG9vc2UgdG8gYnJvYWRjYXN0IGEgCiAgICAgICAgREhDUElO Rk9STSByZXF1ZXN0IGZvciB3aGF0ZXZlciByZWFzb24sIGFuZCBwb2ludHMgb3V0IHRoZSBuZWVk IGZvciAKICAgICAgCiAgICAgSGliYnMgICAgICAgICAgICAgICAgRXhwaXJlczogT2N0IDIwMDMg KyA2IG1vbnRocyAgICAgICAgICAgW1BhZ2UgMTFdIAoKCgoKCgoKCgoKCiAgICAgSW50ZXJuZXQg RHJhZnQgICAgICBSRkMgMjEzMSBJbXBsZW1lbnRhdGlvbiBJc3N1ZXMgICAgICAgT2N0b2JlciAy MDAzIAogICAgICAKICAgICAgICBjbGFyaWZpY2F0aW9uIG9mIGFsbCB0ZXh0IGNvbmNlcm5pbmcg bXVsdGlwbGUgc2VydmVyIHJlc3BvbnNlcyBhbmQgCiAgICAgICAgY29uc2lzdGVuY3kgb2YgcmV0 dXJuZWQgb3B0aW9ucy4gCgogICAgICAgIFJFQ09NTUVOREFUSU9OUzogCgogICAgICAgIG8gIERI Q1BJTkZPUk0gbWVzc2FnZXMgc2hvdWxkIGJlIGluY2x1ZGVkIGluIFRhYmxlIDQgdG8gc3VtbWFy aXplIAogICAgICAgICAgIHRoZSBmaWVsZHMgYW5kIG9wdGlvbnMgdXNhZ2Ugd2l0aCB0aGlzIG1l c3NhZ2UgdHlwZS4gCgogICAgICAgIG8gIFRoZSBXb3JraW5nIEdyb3VwIHNob3VsZCBjb25zaWRl ciB0aGUgcmFtaWZpY2F0aW9ucyBvZiAKICAgICAgICAgICBwZXJtaXR0aW5nIHRoaXJkIHBhcnR5 IERIQ1BJTkZPUk1zLCB0aGF0IGlzLCBESENQSU5GT1JNIAogICAgICAgICAgIG1lc3NhZ2VzIE5P VCBzZW50IGJ5IHRoZSBESENQIGNsaWVudCwgYnV0IGJ5IG90aGVyIHByb2Nlc3NlcyAKICAgICAg ICAgICBoYXZpbmcgYWNjZXNzIHRvIHRoZSBwb3J0cy4gCgogICAgICAgIG8gIFNlY3Rpb24gNC4z LjEsICJESENQRElTQ09WRVIgTWVzc2FnZSwiIGFuZCBzZWN0aW9uIDQuMy4yLCAKICAgICAgICAg ICAiREhDUFJFUVVFU1QgTWVzc2FnZSIgYnJpZWZseSBtZW50aW9uIGNvbnNpc3RlbmN5IGFuZCB1 bmlmb3JtIAogICAgICAgICAgIHJlc3BvbnNlcyBmcm9tIG11bHRpcGxlIHNlcnZlcnM6ICB0aGlz IHRleHQgU0hPVUxEIGJlIGNsYXJpZmllZCAKICAgICAgICAgICB0byBzdGF0ZSB3aGF0IGNvbnNp c3RlbmN5IGlzIGV4cGVjdGVkIG9yIHJlcXVpcmVkIG9mIHRoZSAKICAgICAgICAgICBzZXJ2ZXIs IGFuZCB3aGF0IGEgY2xpZW50IHNob3VsZCBkbyBpZiBhIHNlcnZlciBzdXBwbGllcyAKICAgICAg ICAgICBpbmNvbnNpc3RlbnQgZGF0YS4gCgoKICAgICAyLjExLiBVbmljYXN0IG9mIERIQ1BESVND T1ZFUiAKCiAgICAgICAgU2VjdGlvbiA0LjQuNCBQYXJhIDEsICJVc2Ugb2YgYnJvYWRjYXN0IGFu ZCB1bmljYXN0LCIgaGludHMgdGhhdCAKICAgICAgICBjbGllbnRzIG1heSBiZSBhYmxlIHRvIHVu aWNhc3QgREhDUERJU0NPVkVSIG1lc3NhZ2VzIHRvIHNlcnZlcnM6ICJUaGUgCiAgICAgICAgREhD UCBjbGllbnQgYnJvYWRjYXN0cyBESENQRElTQ09WRVIsIERIQ1BSRVFVRVNUIGFuZCBESENQSU5G T1JNIAogICAgICAgIG1lc3NhZ2VzLCB1bmxlc3MgdGhlIGNsaWVudCBrbm93cyB0aGUgYWRkcmVz cyBvZiBhIERIQ1Agc2VydmVyLiIgCgogICAgICAgIFRoaXMgd291bGQgYmUgcG9pbnRsZXNzIHVu bGVzcyAiY2lhZGRyIiB3ZXJlIG5vbi16ZXJvLCBiZWNhdXNlIHRoZSAKICAgICAgICBzZXJ2ZXIg d291bGQgbm90IGtub3cgaG93IHRvIHJlc3BvbmQuICBOZWl0aGVyIGRvZXMgdGFibGUgNCBhZG1p dCB0aGUgCiAgICAgICAgcG9zc2liaWxpdHkuIAoKICAgICAgICBXZSBiZWxpZXZlIGl0IGlzIGNv bW1vbiBwcmFjdGljZSBmb3IgQk9PVFAgUmVsYXkgQWdlbnRzIHRvIG9ubHkgZmlsbC0KICAgICAg ICBpbiAiZ2lhZGRyIiBmb3IgYnJvYWRjYXN0IHBhY2tldHMuICBUaGlzIHJlcXVpcmVzIGludmVz dGlnYXRpb246ICAKICAgICAgICBzdWNoIGJlaGF2aW9yIHdvdWxkIHJlc3RyaWN0IHRoZSB1c2Ug b2YgdW5pY2FzdCBESENQRElTQ09WRVIgbWVzc2FnZXMgCiAgICAgICAgdG8gdGhlIHNhbWUgc3Vi bmV0IG9uIHdoaWNoIHRoZSBzZXJ2ZXIgcmVzaWRlcyAtLSBhIHZlcnkgcmVzdHJpY3RlZCAKICAg ICAgICBjb25kaXRpb24uIAoKICAgICAgICBPbmUgY2lyY3Vtc3RhbmNlIGluIHdoaWNoIHRoaXMg bWlnaHQgbWFrZSBzZW5zZSBpcyBmb3IgcHJveGllcyAKICAgICAgICBnYXRoZXJpbmcgSVAgYWRk cmVzc2VzIG9uIGJlaGFsZiBvZiBvdGhlciBjbGllbnRzLiAgSW4gdGhhdCBjYXNlIHRoZSAKICAg ICAgICBwcm94eSBjb3VsZCBwdXQgaXRzIG93biBJUCBhZGRyZXNzIGluICJjaWFkZHIiIGFuZCBw ZXJoYXBzIHVzZSAKICAgICAgICBtdWx0aXBsZSBkaWZmZXJlbnQgY2xpZW50IGlkZW50aWZpZXJz IGluIG11bHRpcGxlIHRyYW5zbWlzc2lvbnMuICAKICAgICAgICBUYWJsZSA1LCBob3dldmVyLCBh c3NlcnRzIHRoYXQgY2lhZGRyIG11c3QgYmUgemVyby4gCgogICAgICAgIFJFQ09NTUVOREFUSU9O UzogCgogICAgICAgIG8gIFRoZSBXb3JraW5nIEdyb3VwIHNob3VsZCBjb25zaWRlciB3aGV0aGVy IHRvIGFsbG93IHRoaXMga2luZCBvZiAKICAgICAgICAgICBwcm94eSB1c2FnZSwgYW5kIHdoYXQg Y2hhbmdlcyB0aGF0IG1pZ2h0IGltcGx5IHRvIFJGQyAyMTMxLiAKCgogICAgICAKICAgICBIaWJi cyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICBb UGFnZSAxMl0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMxIElt cGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAgICAgIG8g IFRhYmxlcyA0IGFuZCA1IFNIT1VMRCBiZSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIHBvc3NpYmls aXR5IG9mIAogICAgICAgICAgIHVuaWNhc3QgREhDUERJU0NPVkVSIG1lc3NhZ2VzLiAKCiAgICAg ICAgbyAgRmlndXJlIDUgU0hPVUxEIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUgdXNlcyBvZiB1 bmljYXN0IGFuZCAKICAgICAgICAgICBicm9hZGNhc3QgcGFja2V0cyAKCgogICAgIDIuMTIuIERI Q1BSRUxFQVNFIAoKICAgICAgICBUaGVyZSBhcmUgc2V2ZXJhbCBNVVNUIE5PVCBlbnRyaWVzIGlu IHRoZSAib3B0aW9ucyIgcG9ydGlvbiBvZiBSRkMgCiAgICAgICAgMjEzMSB0YWJsZSA1IHNwZWNp ZnlpbmcgdGhlIGluY2x1c2lvbiBvZiBvcHRpb25zIGluIHRoZSBESENQUkVMRUFTRS4gIAogICAg ICAgIFNvbWUgY3VzdG9tZXJzIGNvbXBsYWluZWQgdGhhdCBhIHBhcnRpY3VsYXIgdmVuZG9yIGlu Y2x1ZGVkIHRoZSAKICAgICAgICAiaG9zdG5hbWUiIG9wdGlvbiBhbmQgdGhhdCB0aGlzIHNlZW1l ZCBpbm5vY3VvdXMuICBUaGUgdmVuZG9yIHNhaWQgCiAgICAgICAgdGhhdCB0aGVpciByZWFkaW5n IG9mIHRoZSBSRkMgYWxsb3dzIHN1Y2ggYW4gb3B0aW9uIHRvIGJlIGluY2x1ZGVkLiAKCiAgICAg ICAgSW4gdGhlICJmaWVsZHMiIHBvcnRpb24gb2YgdGFibGUgNSB0aGVyZSBpcyB0aGUgd29yZCAi dW51c2VkIiBmb3IgdGhlIAogICAgICAgICJzbmFtZSIgYW5kICJmaWxlIiBmaWVsZHMgb2YgYSBE SENQUkVMRUFTRSBtZXNzYWdlLCB3aGlsZSAib3B0aW9ucyIgCiAgICAgICAgZm9yIHRoZSBESENQ UkVMRUFTRSB3YXMgbGVmdCBibGFuay4gCgogICAgICAgIEEgREhDUFJFTEVBU0UgbWVzc2FnZSBT SE9VTEQgYmUgc3ViamVjdCB0byBzb21lIHZlcmlmaWNhdGlvbiBjcml0ZXJpYSAKICAgICAgICB0 byByZWR1Y2UgdGhlIGNoYW5jZSBvZiBhIGJvZ3VzIHJlbGVhc2UuICBUd28gcG9zc2libGUgY2hh bmdlcyB0byAKICAgICAgICB0aGVzZSB0YWJsZXMgYXJlOiAKCiAgICAgICAgMS4gIEluIHRoZSAi ZmllbGRzIiBwb3J0aW9uIG9mIHRhYmxlIDUsIGNoYW5nZSB0aGUgInhpZCIgZnJvbSAKICAgICAg ICAgICAgInNlbGVjdGVkIGJ5IGNsaWVudCIgdG8gInhpZCBmcm9tIHNlcnZlciBESENQQUNLIG1l c3NhZ2UuIiAKCiAgICAgICAgMi4gIEluIHRoZSAib3B0aW9ucyIgcG9ydGlvbiBvZiB0YWJsZSA1 LCBjaGFuZ2UgdGhlIGVudHJ5IGZvciAKICAgICAgICAgICAgImNsaWVudCBpZGVudGlmaWVyIiBm cm9tICJNQVkiIHRvICJjbGllbnQgaWRlbnRpZmllciB1c2VkIGluIAogICAgICAgICAgICB0aGUg REhDUERJU0NPVkVSIG1lc3NhZ2UuIiAKCgogICAgIDIuMTMuIENsaWVudCBzdGF0ZSBkaWFncmFt IAoKICAgICAgICBTZWN0aW9uIDQuMy4xIGFuZCBGaWd1cmUgNSBkbyBub3QgYWNjdXJhdGVseSBk ZXNjcmliZSBESENQIGNsaWVudCAKICAgICAgICBiZWhhdmlvcjogIERIQ1AgY2xpZW50cyBzZW5k IG1lc3NhZ2VzIHRvIHNlcnZlcnMgZnJvbSB0aGUgSU5JVCwgSU5JVC0KICAgICAgICBSRUJPT1Qs IFNFTEVDVElORywgUkVRVUVTVElORywgYW5kIEJPVU5EIHN0YXRlcywgbm90IGZyb20gUkVORVdJ Tkcgb3IgCiAgICAgICAgUkVCSU5ESU5HLiAKCiAgICAgICAgbyAgQ2hhbmdlIHRoZSB0ZXh0IG9m IHNlY3Rpb24gNC4zLjEgYW5kIGl0J3Mgc2NoZW1hdGljIAogICAgICAgICAgIHJlcHJlc2VudGF0 aW9uIGluIEZpZ3VyZSA1IHRvIGNvcnJlY3RseSByZXByZXNlbnQgdGhlIHN0YXRlcywgCiAgICAg ICAgICAgdHJhbnNpdGlvbnMsIHRyaWdnZXJpbmcgZXZlbnRzLCBhbmQgbWVzc2FnZXMgc2VudC4g CgoKICAgICAyLjE0LiBPcHRpb25zIAoKICAgICAgICBUaGUgbGFuZ3VhZ2UgaW4gUkZDIDIxMzEg Y29uY2VybmluZyB3aGV0aGVyIGFuZCB3aGljaCBvcHRpb25zIHRvIAogICAgICAgIHJldHVybiB0 byB0aGUgY2xpZW50IGlzIGNvbnZvbHV0ZWQgYW5kIGFwcGFyZW50bHkgY29udHJhZGljdG9yeS4g CgoKCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAzICsg NiBtb250aHMgICAgICAgICAgIFtQYWdlIDEzXSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0IERy YWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIgMjAw MyAKICAgICAgCiAgICAgMi4xNC4xLiBXaGljaCBPcHRpb25zIHRvIFJldHVybj8gCgogICAgICAg IFRoZXJlIGFyZSB0d28gb3Bwb3NpbmcgcGhpbG9zb3BoaWVzIHJlZ2FyZGluZyB3aGljaCBvcHRp b25zIHNlcnZlcnMgCiAgICAgICAgc2hvdWxkIHJldHVybiB0byBjbGllbnRzOiAgdG8gcmV0dXJu IGV2ZXJ5IG9wdGlvbiB3aXRoIHZhbHVlcyB3aXRoaW4gCiAgICAgICAgdGhlIGNsaWVudJJzIHNj b3BlLCBvciB0byByZXR1cm4gb25seSB0aG9zZSBvcHRpb25zIHNwZWNpZmljYWxseSAKICAgICAg ICByZXF1ZXN0ZWQgYnkgYSBjbGllbnQgYW5kIHdpdGhpbiBzY29wZS4gIFRoZSBmb2xsb3dpbmcg YXJndW1lbnRzIGhhdmUgCiAgICAgICAgYmVlbiBjaXRlZDogCgogICAgICAgIFN1cHBvcnRpbmcg dGhlIHJldHVybiBvZiBldmVyeSBvcHRpb246IAoKICAgICAgICBvICBDb25zaXN0ZW5jeS4gIEEg bmV0d29yayBhZG1pbmlzdHJhdG9yIHdhbnRzIGFsbCBvZiB0aGUgCiAgICAgICAgICAgY29uZmln dXJlZCBvcHRpb25zIHRvIHNob3cgdXAgb24gZWFjaCBjbGllbnQgb24gdGhlIG5ldHdvcmssIAog ICAgICAgICAgIHJlZ2FyZGxlc3Mgb2YgY2xpZW50IHZlbmRvci4gCgogICAgICAgIG8gIEEgREhD UCBjbGllbnQgaXMgbGlrZWx5IG9ubHkgdG8gcmVxdWVzdCB0aGUgb3B0aW9ucyBpdCAKICAgICAg ICAgICBzdXBwb3J0cy4gIEhvd2V2ZXIsIG1hbnkgYXBwbGljYXRpb24gbGF5ZXIgb3B0aW9ucyBh cmUgbm90IHVzZWQgCiAgICAgICAgICAgYnkgdGhlIERIQ1AgY2xpZW50IGJ1dCBhcmUgdXNlZnVs IHRvIGFwcGxpY2F0aW9ucy4gCgogICAgICAgIG8gIEEgREhDUCBjbGllbnQgd291bGQgZWl0aGVy IG5lZWQgdG8gYmUgY29uZmlndXJlZCBvciB1cGRhdGVkIHRvIAogICAgICAgICAgIHJlcXVlc3Qg bmV3IG9wdGlvbnMuICBUaGUgd2hvbGUgaWRlYSBvZiBESENQIGlzIHRvIGtlZXAgCiAgICAgICAg ICAgY29uZmlndXJhdGlvbiBvbiB0aGUgc2VydmVyLCBub3Qgb24gdGhlIGNsaWVudCwgd2hpY2gg aXMgCiAgICAgICAgICAgcG9pbnRlZCBvdXQgaW46ICBQYWdlIDcsIHNlY29uZCBhbmQgdGhpcmQg YnVsbGV0cyBvZiBzZWN0aW9uIAogICAgICAgICAgIDEuNi4gCgogICAgICAgIFN1cHBvcnRpbmcg dGhlIHJldHVybiBvbmx5IG9mIHJlcXVlc3RlZCBvcHRpb25zOiAKCiAgICAgICAgbyAgU29tZSBE SENQIGNsaWVudHMgbWF5IHJlamVjdCBwYWNrZXRzIGNvbnRhaW5pbmcgb3B0aW9ucyB0aGF0IAog ICAgICAgICAgIHRoZXkgZGlkIG5vdCByZXF1ZXN0IGVzcGVjaWFsbHkgaWYgdGhleSBhcmUgaWdu b3JhbnQgb2YgdGhlaXIgCiAgICAgICAgICAgc2VtYW50aWNzOyB0aGVyZWZvcmUgYSBESENQIHNl cnZlciBzaG91bGQgb25seSByZXR1cm4gdGhlIAogICAgICAgICAgIG9wdGlvbnMgcmVxdWVzdGVk LiAKCiAgICAgICAgbyAgVGhlIERIQ1AgcGFja2V0IHNpemUgaXMgbGltaXRlZC4gIE9wdGlvbnMg YXJlIG9mdGVuIGNvbmZpZ3VyZWQgCiAgICAgICAgICAgb24gYSBwZXItbmV0d29yayByYXRoZXIg dGhhbiBhIHBlci1jbGllbnQgYmFzaXMsIGFuZCB0byByZXR1cm4gCiAgICAgICAgICAgdW53YW50 ZWQgb3B0aW9ucyByaXNrcyBleGhhdXN0aW5nIHRoZSBzcGFjZSBhdmFpbGFibGUgd2hpbGUgCiAg ICAgICAgICAgb3B0aW9ucyByZW1haW4gd2hpY2ggdGhlIGNsaWVudCBuZWVkcy4gCgogICAgICAg IFJGQyAyMTMxIGRvZXMgbGl0dGxlIHRvIHJlc29sdmUgdGhlIG1hdHRlci4gIFR3byBkaWZmZXJl bnQgc2VjdGlvbnMgCiAgICAgICAgYXJlIHJlbGV2YW50OiBzZWN0aW9uIDMuNSBkZXNjcmliZXMg bWVjaGFuaXNtcyB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIAogICAgICAgIG9wdGlvbnMgc2VudCwg d2hpbGUgc2VjdGlvbiA0LjMuMSBzdWJzZXF1ZW50bHkgcHJlc2VudHMgYW4gYXBwYXJlbnRseSAK ICAgICAgICBjb25mbGljdGluZyBkZXNjcmlwdGlvbiBvZiBob3cgdG8gc2VsZWN0IHZhbHVlcyBm b3Igb3B0aW9ucyByZXF1ZXN0ZWQgCiAgICAgICAgYnkgdGhlIGNsaWVudC4gICAKCiAgICAgICAg UkZDIDIxMzEsIFNlY3Rpb24gMy41OiAKCiAgICAgICAgICAgIkZpcnN0LCBtb3N0IHBhcmFtZXRl cnMgaGF2ZSBkZWZhdWx0cyBkZWZpbmVkIGluIHRoZSBIb3N0IAogICAgICAgICAgIFJlcXVpcmVt ZW50cyBSRkNzOyBpZiB0aGUgY2xpZW50IHJlY2VpdmVzIG5vIHBhcmFtZXRlcnMgZnJvbSAKICAg ICAgICAgICB0aGUgc2VydmVyIHRoYXQgb3ZlcnJpZGUgdGhlIGRlZmF1bHRzLCBhIGNsaWVudCB1 c2VzIHRob3NlIAogICAgICAgICAgIGRlZmF1bHQgdmFsdWVzLiIgCgoKICAgICAgCiAgICAgSGli YnMgICAgICAgICAgICAgICAgRXhwaXJlczogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAgICAgICAg W1BhZ2UgMTRdIAoKCgoKCgoKCgoKCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICBSRkMgMjEzMSBJ bXBsZW1lbnRhdGlvbiBJc3N1ZXMgICAgICAgT2N0b2JlciAyMDAzIAogICAgICAKICAgICAgICBU aGUgbGlzdCBvZiBwYXJhbWV0ZXJzIHdpdGggYSBjcm9zcy1yZWZlcmVuY2UgdG8gdGhlIGRlZmlu aW5nIFJGQyBpcyAKICAgICAgICBnaXZlbiBpbiBBcHBlbmRpeCBBIG9mIFJGQyAyMTMxLiAKCiAg ICAgICAgU2V2ZXJhbCBzb3VyY2VzIGNvbnRlbmQgdGhhdCB2aXJ0dWFsbHkgbm9uZSBvZiB0aGUg cGFyYW1ldGVycyBpbiB0aGUgCiAgICAgICAgbGlzdCBoYXZlIGEgbWVhbmluZ2Z1bCBkZWZhdWx0 IHZhbHVlLCB3aGljaCByYWlzZXMgdGhlIGlzc3VlIG9mIAogICAgICAgIHZpYWJpbGl0eSBvZiB0 aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24gZm9yIHJlZHVjaW5nIAogICAg ICAgIHRvdGFsIHNlcnZlciByZXNwb25zZSBtZXNzYWdlIHNpemUuIAoKICAgICAgICBFdmVuIGlm IHRoZSBvcHRpb24gaGFzIGEgZGVmYXVsdCB2YWx1ZSBkZWZpbmVkIGluIFtSRkMxMTIyXSwgUkZD IDIxMzEgCiAgICAgICAgaXMgc2lsZW50IG9uIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIG9yIG5v dCB0aGUgc2VydmVyIE1VU1QsIFNIT1VMRCwgCiAgICAgICAgb3IgTUFZIGNob29zZSBub3QgdG8g c2VuZCB0aGF0IG9wdGlvbiB3aGVuIGl0cyB2YWx1ZSBpcyB0aGUgc2FtZSBhcyAKICAgICAgICB0 aGUgZGVmYXVsdC4gCgogICAgICAgIFJGQyAyMTMxLCBTZWN0aW9uIDQuMy46IAoKICAgICAgICAg ICAiSUYgdGhlIHNlcnZlciBoYXMgYmVlbiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgd2l0aCBhIGRl ZmF1bHQgCiAgICAgICAgICAgdmFsdWUgZm9yIHRoZSBwYXJhbWV0ZXIsIHRoZSBzZXJ2ZXIgTVVT VCBpbmNsdWRlIHRoYXQgdmFsdWUgaW4gCiAgICAgICAgICAgYW4gYXBwcm9wcmlhdGUgb3B0aW9u IGluIHRoZSAnb3B0aW9uJyBmaWVsZCwgRUxTRSAKCiAgICAgICAgICAgIklGIHRoZSBzZXJ2ZXIg cmVjb2duaXplcyB0aGUgcGFyYW1ldGVyIGFzIGEgcGFyYW1ldGVyIGRlZmluZWQgCiAgICAgICAg ICAgaW4gdGhlIEhvc3QgUmVxdWlyZW1lbnRzIERvY3VtZW50LCB0aGUgc2VydmVyIE1VU1QgaW5j bHVkZSB0aGUgCiAgICAgICAgICAgZGVmYXVsdCB2YWx1ZSBmb3IgdGhhdCBwYXJhbWV0ZXIgYXMg Z2l2ZW4gaW4gdGhlIEhvc3QgCiAgICAgICAgICAgUmVxdWlyZW1lbnRzIERvY3VtZW50IGluIGFu IGFwcHJvcHJpYXRlIG9wdGlvbiBpbiB0aGUgJ29wdGlvbicgCiAgICAgICAgICAgZmllbGQsIEVM U0UgCgogICAgICAgICAgICJUaGUgc2VydmVyIE1VU1QgTk9UIHJldHVybiBhIHZhbHVlIGZvciB0 aGF0IHBhcmFtZXRlci4iIAoKICAgICAgICBUaGUgd29yZCAiZGVmYXVsdCIgaW4gdGhlIGZpcnN0 IHN0YXRlbWVudCBzZWVtcyBtaXNwbGFjZWQuICBUaGUgCiAgICAgICAgc2Vjb25kIHN0YXRlbWVu dCBzZWVtcyBjb250cmFyeSB0byB0aGUgaW50ZW50IG9mIG1pbmltaXppbmcgdGhlIAogICAgICAg IGFtb3VudCBvZiBkYXRhIHNlbnQgYnkgdGhlIHNlcnZlcjogIGlmIHRoZSBzY29wZSBvZiB0aGUg SG9zdCAKICAgICAgICBSZXF1aXJlbWVudHMgUkZDcyBhcHBsaWVzIHRvIGFsbCBJbnRlcm5ldC1j b25uZWN0ZWQgaG9zdHMsIHRoZW4gYSAKICAgICAgICBESENQIHNlcnZlciBTSE9VTEQgTk9UIGhh dmUgdG8gc3VwcGx5IHRoZXNlIHZhbHVlcyAtLSB0aGV5IHNob3VsZCAKICAgICAgICBhbHJlYWR5 IGJlIGFzc3VtZWQgYnkgdGhlIGNsaWVudCBhcyB0aGUgZGVmYXVsdCBmb3IgdGhlIHJlcXVlc3Rl ZCAKICAgICAgICBvcHRpb24uIAoKICAgICAgICBUaGVyZSBpcyBubyBtZW50aW9uIG9mIGEgbWlu aW11bSBzZXQgb2YgcGFyYW1ldGVycyB0byBiZSBzZW50IHRvIGEgCiAgICAgICAgcmVxdWVzdGlu ZyBjbGllbnQsIG5vciBhbnkgbWVudGlvbiBvZiB3aGljaCBwYXJhbWV0ZXJzIHRvIHNlbmQgaWYg dGhlIAogICAgICAgIGNsaWVudCBkb2VzIG5vdCByZXF1ZXN0IGFueSBub3QgYW55IGd1aWRhbmNl IGZvciB3aGF0IHRvIGRvIHdoZW4gCiAgICAgICAgdGhlcmUgaXMgbW9yZSBkYXRhIHRoYW4gd2ls bCBmaXQgaW4gYSByZXNwb25zZSBwYWNrZXQuICBDYW4gdGhlIAogICAgICAgIG9wdGlvbnMgYmUg c29tZWhvdyBwcmlvcml0aXplZD8gIENvdWxkIGFkZGl0aW9uYWwgb3B0aW9ucyBiZSBvYnRhaW5l ZCAKICAgICAgICB1c2luZyB0aGUgREhDUElORk9STSBtZWNoYW5pc20/ICBTaG91bGQgYW4gYWRk aXRpb25hbCBiaXQgaW4gdGhlIAogICAgICAgICJmbGFncyIgZmllbGQgYmUgZGVmaW5lZCBhcyBh ICJwYWNrZXQgb3ZlcmZsb3ciIGJpdD8gCgogICAgICAgIFJFQ09NTUVOREFUSU9OUzogCgogICAg ICAgIG8gIENsaWVudHMgTVVTVCBpbmNsdWRlIHRoZSBzYW1lIHBhcmFtZXRlciByZXF1ZXN0IGxp c3Qgb24gYWxsIAogICAgICAgICAgIG1lc3NhZ2VzLiAgIAoKCgogICAgICAKICAgICBIaWJicyAg ICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICBbUGFn ZSAxNV0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMxIEltcGxl bWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAgICAgIG8gIENs aWVudHMgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIHJlc3BvbnNlcyBjb250YWluaW5nIAog ICAgICAgICAgIG9wdGlvbnMgdGhleSBkaWQgbm90IHJlcXVlc3QgYW5kL29yIHdob3NlIHNlbWFu dGljcyBhcmUgCiAgICAgICAgICAgdW5rbm93bi4gIFRoZXkgTUFZIGNob29zZSBzaWxlbnRseSB0 byBpZ25vcmUgc3VjaCBvcHRpb25zLiAKCiAgICAgICAgbyAgTGFuZ3VhZ2UgaW1wbHlpbmcgdGhh dCBwYXJhbWV0ZXJzIGluICJSZXF1aXJlbWVudHMgZm9yIEludGVybmV0IAogICAgICAgICAgIEhv c3RzIiBoYXZlIGRlZmF1bHRzIHNob3VsZCBiZSByZW1vdmVkLiAKCgogICAgIDIuMTQuMi4gTXVs dGlwbGUgSW5zdGFuY2VzIG9mIE9wdGlvbnMgCgogICAgICAgIFBhZ2UgMjQsIHNldmVudGggcGFy YWdyYXBoLCBzZWN0aW9uIDQuMTogICJPcHRpb25zIG1heSBhcHBlYXIgb25seSAKICAgICAgICBv bmNlLCB1bmxlc3Mgb3RoZXJ3aXNlIHNwZWNpZmllZCBpbiB0aGUgb3B0aW9ucyBkb2N1bWVudC4g IFRoZSBjbGllbnQgCiAgICAgICAgY29uY2F0ZW5hdGVzIHRoZSB2YWx1ZXMgb2YgbXVsdGlwbGUg aW5zdGFuY2VzIG9mIHRoZSBzYW1lIG9wdGlvbiBpbnRvIAogICAgICAgIGEgc2luZ2xlIHBhcmFt ZXRlciBsaXN0IGZvciBjb25maWd1cmF0aW9uLiIgIFRoZSBmaXJzdCBzZW50ZW5jZSAKICAgICAg ICBzaG91bGQgc3RhcnQgb3V0ICJPcHRpb25zIE1VU1QgYXBwZWFyIG9ubHkgb25jZSwgdW5sZXNz Li4uLiIgIFRoZSAKICAgICAgICBzZWNvbmQgc2VudGVuY2UgYmVsb25ncyBpbiB0aGUgb3B0aW9u cyBtZW1vIFtSRkMyMTMyXSBmb3Igb3B0aW9ucyAKICAgICAgICB3aGVyZSB0aGVyZSBjYW4gYmUg bXVsdGlwbGUgaW5zdGFuY2VzLiAgVG9nZXRoZXIsIHRoZXNlIHR3byBzZW50ZW5jZXMgCiAgICAg ICAgYXJlIGNvbmZ1c2luZy4gCgoKICAgICAyLjE0LjMuIE9wdGlvbiBPcmRlcmluZyAKCiAgICAg ICAgQSBudW1iZXIgb2YgY2xpZW50cyByZXF1aXJlIHRoYXQgdGhlIERIQ1AgbWVzc2FnZSB0eXBl IGJlIHRoZSBmaXJzdCAKICAgICAgICBvcHRpb24gKGFmdGVyIHRoZSBtYWdpYyBjb29raWUpLiAK CiAgICAgICAgUkVDT01NRU5EQVRJT05TOiAKCiAgICAgICAgbyAgV2l0aCB0aGUgZXhjZXB0aW9u IG9mIG9wdGlvbiA4Miwgd2hpY2ggbXVzdCBiZSBsYXN0IChzYXZlIAogICAgICAgICAgIG9wdGlv biAyNTUgd2hpY2ggYWN0cyBhcyBhIHRlcm1pbmF0b3IpLCB0aGUgY2xpZW50IE1VU1QgTk9UIAog ICAgICAgICAgIG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIG9yZGVyaW5nIG9mIG9wdGlv bnMuIAoKCiAgICAgMi4xNC40LiAgDSAgICAgICAgICAgICAgDSAgICAgICAgICAgICBPcHRpb25z IDY2IGFuZCA2NyAKCiAgICAgICAgT3B0aW9ucyA2NiAoVEZUUCBzZXJ2ZXIgbmFtZSkgYW5kIDY3 IChib290ZmlsZSBuYW1lKSB3ZXJlIGludHJvZHVjZWQgCiAgICAgICAgYXMgYW4gYWx0ZXJuYXRp dmUgdG8gdGhlIGZpeGVkIGZpZWxkcyAic25hbWUiIGFuZCAiZmlsZSIgaW4gQk9PVFAuICAKICAg ICAgICBBcyBkaXNjdXNzZWQgZWxzZXdoZXJlLCBzcGFjZSBpcyBhdCBhIHByZW1pdW0gaW4gREhD UCwgYW5kIHJlc2VydmluZyAKICAgICAgICA2NCBvY3RldHMgKCJzbmFtZSIpIGFuZCAxMjggb2N0 ZXRzICgiZmlsZSIpIHRvIGNvbnRhaW4gdmFsdWVzIGFyZSAKICAgICAgICB0aGF0IHBvdGVudGlh bGx5LCBhbmQgY29tbW9ubHksIG11Y2ggc2hvcnRlciBpcyB3YXN0ZWZ1bC4gIAogICAgICAgIEZ1 cnRoZXJtb3JlLCB0aGUgZXhpc3RlbmNlIG9mIHRoZXNlIG9wdGlvbnMgYWxsb3dzIHRoZSBjbGll bnQgdG8gCiAgICAgICAgZWl0aGVyIHJlcXVlc3QgdGhvc2UgdmFsdWVzIGZyb20gdGhlIHNlcnZl ciBvciBub3QsIGFjY29yZGluZyB0byAKICAgICAgICBuZWVkLiAKCiAgICAgICAgQXQgcHJlc2Vu dCwgc2VydmVycyBhcmUgYXQgbGliZXJ0eSB0byByZXR1cm4gdmFsdWVzIGZvciB0aGVzZSBvcHRp b25zIAogICAgICAgIGluIGVpdGhlciB0aGUgZml4ZWQgZmllbGRzLCBvciBlbmNhcHN1bGF0ZWQg bGlrZSBhbnkgb3RoZXIgREhDUCAKICAgICAgICBvcHRpb24uICBDbGllbnRzIGhhdmUgc29tZXRp bWVzIGFzc3VtZWQgb25seSB0aGUgZm9ybWVyLiAgUkZDIDIxMzEgCiAgICAgICAgc2hvdWxkIGFk ZHJlc3MgdGhpcyBpc3N1ZS4gCgogICAgICAgIFJFQ09NTUVOREFUSU9OUzogCgogICAgICAKICAg ICBIaWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAg ICAgICBbUGFnZSAxNl0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAy MTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAg ICAgIG8gIFVzaW5nICJzbmFtZSIgYW5kICJmaWxlIiBmb3IgdGhlc2Ugb3B0aW9ucyBTSE9VTEQg YmUgCiAgICAgICAgICAgZGVwcmVjYXRlZC4gCgogICAgICAgIG8gIENsaWVudHMgTVVTVCBiZSBw cmVwYXJlZCwgYXQgbGVhc3QgZm9yIHRoZSB0aW1lIGJlaW5nLCBmb3IgCiAgICAgICAgICAgZWl0 aGVyIG1ldGhvZCBvZiBkZWxpdmVyeS4gCgoKICAgICAyLjE1LiBWZW5kb3IgQ2xhc3NlcyAKCiAg ICAgICAgUGFnZSAzLCBzZWN0aW9uIDEuMSwgZmlyc3QgcGFyYWdyYXBoIC0gaW5jbHVkZXMgdGhl IGZvbGxvd2luZyAKICAgICAgICBzZW50ZW5jZTogICJUaGUgY2xhc3NpbmcgbWVjaGFuaXNtIGZv ciBpZGVudGlmeWluZyBESENQIGNsaWVudHMgdG8gCiAgICAgICAgREhDUCBzZXJ2ZXJzIGhhcyBi ZWVuIGV4dGVuZGVkIHRvIGluY2x1ZGUgInZlbmRvciIgY2xhc3NlcyBhcyBkZWZpbmVkIAogICAg ICAgIGluIHNlY3Rpb25zIDQuMiBhbmQgNC4zLiIgIFZlbmRvciBjbGFzc2luZyBoYXMgYmVlbiB0 aGVyZSBzaW5jZSBSRkMgCiAgICAgICAgMTU0MSwgdGh1cyB0aGVyZSBpcyBub3RoaW5nIG5ldyBh Ym91dCBpdC4gIFNob3VsZCB0aGlzIHNlY3Rpb24gYmUgCiAgICAgICAgcmVmZXJyaW5nIHRvIFVz ZXIgY2xhc3Npbmc/IAoKCiAgICAgMi4xNS4xLiBDaGFyYWN0ZXIgc2V0ICAKCiAgICAgICAgU29t ZSBuZXcgY2xpZW50cyBoYXZlIHNwYWNlcyBpbiB0aGVpciBpZGVudGlmaWVyLCB3aGljaCBicm9r ZSBzb21lIAogICAgICAgIGltcGxlbWVudGF0aW9ucyB3aXRoIGNvbmZpZ3VyYXRpb24gZmlsZSBy ZWNvcmRzIGRlbGltaXRlZCBieSAKICAgICAgICB3aGl0ZXNwYWNlLiAKCgogICAgIDIuMTUuMi4g Rm9ybSBvZiB0aGUgbmFtZSBzcGFjZSAKCiAgICAgICAgQW4gZWFybHkgc3VnZ2VzdGlvbiAoUkZD IDE1NDEgdGltZS1mcmFtZSksIGV4cHJlc3NlZCBzeW1ib2xpY2FsbHksIAogICAgICAgIHdhcyB0 aGUgZm9ybSAiU3RvY2sgc3ltYm9sL09yZ2FuaXphdGlvbi4uLi4iIGUuZy4sICJTVU5XLmNsYXNz LQogICAgICAgIDEuY2xhc3MtMiIgb3IgIkNNVS5lZHUuY2xhc3MtMS5jbGFzcy0yIi4gIFRoaXMg d291bGQgaGF2ZSBoYWQgdGhlIAogICAgICAgIGFkdmFudGFnZSBvZiBwcmV2ZW50aW5nIGNvbGxp c2lvbnMgYmV0d2VlbiB2ZW5kb3JzLiAgVGhpcyB3YXMgbm90IAogICAgICAgIGFkb3B0ZWQsIGFu ZCBpdCBpcyBwcm9iYWJseSB0b28gbGF0ZSB0byByZXN1cnJlY3QgaXQuIAoKCiAgICAgMi4xNS4z LiBSZWxhdGlvbnNoaXAgdG8gdmVuZG9yIG9wdGlvbnMgCgogICAgICAgIFRleHQgaXMgbmVlZGVk IGRlc2NyaWJpbmcgaG93IGVhY2ggdW5pcXVlIHZlbmRvciBjbGFzcyBpZGVudGlmaWVyIAogICAg ICAgIGltcGxpZXMgYSAyNTQgdW5pcXVlIGVuY2Fwc3VsYXRlZCBvcHRpb24gbmFtZSBzcGFjZS4g IFRoZXJlIGFyZSAyNTQsIAogICAgICAgIGJlY2F1c2UgZXZlbiB3aXRoaW4gdGhlIHZlbmRvciBz cGFjZSBvcHRpb25zIDAgYW5kIDI1NSByZXRhaW4gdGhlaXIgCiAgICAgICAgbWVhbmluZyBhcyB0 aGUgcGFkIHZhbHVlIGFuZCB0ZXJtaW5hdG9yLCByZXNwZWN0aXZlbHkuICBBbiBvY2Nhc2lvbmFs IAogICAgICAgIG1pc2NvbmNlcHRpb24gaXMgdGhhdCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIHVu aXF1ZSBlbmNhcHN1bGF0ZWQgMjU0IAogICAgICAgIG9wdGlvbiBuYW1lIHNwYWNlIHNoYXJlZCBi eSBhbGwgdmVuZG9ycywgd2l0aCB0aGUgZWZmZWN0IHRoYXQgdGhlIAogICAgICAgIHNhbWUgdmFs dWVzIGJlaW5nIHJldHVybmVkIHRvICphbnkqIGNsaWVudCByZWdhcmRsZXNzIG9mIHZlbmRvciBj bGFzcyAKICAgICAgICBpZGVudGlmaWVyLiAgT2J2aW91c2x5LCB3ZSBzaG91bGQgaW5jbHVkZSB0 ZXh0IHRvIGNsYXJpZnkgdGhlIAogICAgICAgIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFZlbmRvciBD bGFzcyBpZGVudGlmaWVyIGFuZCB0aGUgZW5jYXBzdWxhdGVkIAogICAgICAgIFZlbmRvciBvcHRp b24uIAoKCgoKCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAy MDAzICsgNiBtb250aHMgICAgICAgICAgIFtQYWdlIDE3XSAKCgoKCgoKCgoKCgogICAgIEludGVy bmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9i ZXIgMjAwMyAKICAgICAgCiAgICAgMi4xNS40LiBNdWx0aXBsaWNpdHkuIAoKICAgICAgICBIb3cg bWFueSB2ZW5kb3IgY2xhc3MgaWRlbnRpZmllcnMgY2FuIGEgY2xpZW50IGhhdmU/ICBPbmUgb25s eSwgCiAgICAgICAgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHVuaXF1ZSB0byBhIHNwZWNpZmljIHZl bmRvci4gIElmIHRoZSBjbGllbnQgCiAgICAgICAgd2VyZSB0byBzZW5kIG1vcmUgdGhhbiBvbmUg dmVuZG9yIGNsYXNzIG9wdGlvbiBpdCB3b3VsZCBiZSBpbXBvc3NpYmxlIAogICAgICAgIGZvciB0 aGUgc2VydmVyIHRvIGRlY2lkZSB3aGljaCBzZXQgb2YgZW5jYXBzdWxhdGVkIHZlbmRvciBvcHRp b25zIHRvIAogICAgICAgIHNlbGVjdC4gCgogICAgICAgIEhlcmUgaXMgc29tZSBtb3JlIHRleHQg cmVnYXJkaW5nIHZlbmRvciBvcHRpb25zIGZyb20gYSBub3RlIGZyb20gTWlrZSAKICAgICAgICBD YXJuZXkgcmVnYXJkaW5nIHRoZSB1c2Ugb2YgdmVuZG9yIGNsYXNzIC8gZW5jYXBzdWxhdGVkIG9w dGlvbnM6IAoKICAgICAgICAgICBWZW5kb3IgY2xhc3Mgc3VwcG9ydCByZXF1aXJlcyB0aGUgYWJp bGl0eSB0byBjb25maWd1cmUgYSBESENQIAogICAgICAgICAgIHNlcnZlciB0byBzdXBwb3J0IGEg bmV3IHZlbmRvciBjbGFzcyBieSBhc3NvY2lhdGluZyB0aGF0IHZlbmRvciAKICAgICAgICAgICBj bGFzcyBpZGVudGlmaWVyIHdpdGggMjU0IG9wdGlvbnMgd2hvc2UgdHlwZXMgY2FuIHRoZW4gYmUg CiAgICAgICAgICAgZGVmaW5lZCBieSBmb2xsb3dpbmcgdGhlIERIQ1AgY2xpZW50J3MgZG9jdW1l bnRhdGlvbi4gIEVhY2ggCiAgICAgICAgICAgZ3JvdXAgb2YgMjU0IG9wdGlvbnMgaGFzIHRoZSAi c2NvcGUiIG9mIHRoYXQgdmVuZG9yLiAgRm9yIAogICAgICAgICAgIGV4YW1wbGUsIHN1cHBvc2Ug d2UgaGF2ZSB0aGUgZm9sbG93aW5nIHR3byBjbGllbnRzOiAKCiAgICAgICAgICAgVmVuZG9yIENs YXNzICJTdW5CZWFtLlRvYXN0ZXIuMnNsb3RzIiAKCiAgICAgICAgICAgT3B0aW9ucyBmb3IgdGhp cyBjbGFzczogCgogICAgICAgICAgIENvZGUgIExlbiAgRGF0YSAKCiAgICAgICAgICAgICAxICAg IDIgICBEYXJrbmVzcyBzZXR0aW5nICAgKCBhIDIgYnl0ZSBpbnRlZ2VyKSAKCiAgICAgICAgICAg IAoKICAgICAgICAgICBWZW5kb3IgQ2xhc3MgIlZveHBvcHVsaXMuQW5zd2VyaW5nLk1hY2hpbmUi IAoKICAgICAgICAgICBPcHRpb25zIGZvciB0aGlzIGNsYXNzOiAKCiAgICAgICAgICAgQ29kZSAg TGVuICBEYXRhICAgKFggYnl0ZXMgQVNDQ0kgc3RyaW5nLCBvZiB0aGUgYW5zd2VyIG1lc3NhZ2Up IAoKICAgICAgICAgICAgIDEgICAgWCAgIE91dGdvaW5nIG1lc3NhZ2UgCgogICAgICAgIEJvdGgg Y2xpZW50cyBhcmUgb24gdGhlIHNhbWUgbmV0d29yayAoIktpdGNoZW4iKSwgYW5kIGFyZSBjbGll bnRzIG9mIAogICAgICAgIHRoZSBzYW1lIERIQ1Agc2VydmVyLiAgTm90ZSB0aGF0IGJvdGggdXNl IGVuY2Fwc3VsYXRlZCBvcHRpb24gY29kZSAxLiAgCiAgICAgICAgTG9va3MgbGlrZSBhIGNvbmZs aWN0LCBidXQgaXQgaXNuJ3QuIAoKICAgICAgICBJbiB0aGUgc3ludGF4IG9mIHRoZSBESENQIHNl cnZlcidzIGNvbmZpZ3VyYXRpb24gdGFibGUsIG9uZSAKICAgICAgICBjb25maWd1cmVzIHR3byBu ZXcgb3B0aW9ucywgZWFjaCB3aGljaCBoYXMgdGhlICJzY29wZSIgb2YgdGhlIHZlbmRvciAKICAg ICAgICBjbGFzcy4gCgogICAgICAgIFdoYXQgdGhpcyBtZWFucyBpcyB0aGF0IHdoZW4gdGhlIHRv YXN0ZXIgYm9vdHMsIHRoZSBESENQIHNlcnZlciBvbmx5IAogICAgICAgIHJldHVybnMgdmVuZG9y IGNsYXNzIG9wdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoZSAKICAgICAgICAiU3VuQmVhbS5Ub2Fz dGVyLjJzbG90cyIgY2xhc3MuICBXaGVuIHRoZSBhbnN3ZXJpbmcgbWFjaGluZSBib290cywgaXQg CiAgICAgICAgb25seSBzZWVzIHZlbmRvciBjbGFzcyBvcHRpb25zIGFzc29jaWF0ZWQgd2l0aCB0 aGUgCiAgICAgICAgIkdFLkFuc3dlcmluZy5NYWNoaW5lIiBjbGFzcy4gIENsaWVudHMgb2YgdmVu ZG9yIGNsYXNzZXMgbm90IAoKICAgICAgCiAgICAgSGliYnMgICAgICAgICAgICAgICAgRXhwaXJl czogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAgICAgICAgW1BhZ2UgMThdIAoKCgoKCgoKCgoKCiAg ICAgSW50ZXJuZXQgRHJhZnQgICAgICBSRkMgMjEzMSBJbXBsZW1lbnRhdGlvbiBJc3N1ZXMgICAg ICAgT2N0b2JlciAyMDAzIAogICAgICAKICAgICAgICBjdXJyZW50bHkgY29uZmlndXJlZCBvbiB0 aGUgc2VydmVyIGRvbid0IHNlZSBhbnkgZW5jYXBzdWxhdGVkIHZlbmRvciAKICAgICAgICBvcHRp b25zLiAKCgogICAgIDIuMTYuIENsaWVudC9TZXJ2ZXIgUmV0cmFuc21pc3Npb24gCgogICAgICAg IEJlY2F1c2UgREhDUCBzZXJ2ZXJzIGFyZSB0aGUgcGFzc2l2ZSBwYXJ0aWNpcGFudHMgYW5kIERI Q1AgY2xpZW50cyAKICAgICAgICBhcmUgdGhlIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIHRoZSBESENQ IHByb3RvY29sIGlzIHN1c2NlcHRpYmxlIHRvIAogICAgICAgIHBvb3JseSBiZWhhdmVkIGNsaWVu dHMgKHJldHJhbnNtaXR0aW5nIHRvbyBmYXN0LCBmb3IgZXhhbXBsZSkuICAKICAgICAgICBIb3dl dmVyLCB0aGVyZSBpcyBubyB0ZXh0IGRlc2NyaWJpbmcgdGhpcyBzdXNjZXB0aWJpbGl0eS4gIAog ICAgICAgIEZ1cnRoZXJtb3JlLCB0aGUgdXNlIG9mIHRoZSBwb3dlci1vZi0yIHJldHJhbnNtaXNz aW9uIGFsZ29yaXRobSBpcyBhIAogICAgICAgIFNIT1VMRC9NQVkuICBUaGlzIHByb2JhYmx5IHNo b3VsZCBiZSBhIE1VU1QuICBJZiB3ZSBuZWVkIGRpZmZlcmVudCAKICAgICAgICByZXRyYW5zbWlz c2lvbiBhbGdvcml0aG1zIGZvciBkaWZmZXJlbnQgbWVkaWEsIHRoZW4gd2Ugc2hvdWxkIAogICAg ICAgIGRldmVsb3AvZG9jdW1lbnQgdGhlbSBpbiB0YWJsZSBmb3JtLiAgVGhlIHNwZWNpZmljYXRp b24gYXMgaXQgc3RhbmRzIAogICAgICAgIGlzIHRvbyBsb29zZSBhbmQgZG9lcyBjYXVzZSBpbnRl ci1vcGVyYWJpbGl0eSBwcm9ibGVtczogCgogICAgICAgIDEuICBQYWdlIDE2LCBzZWN0aW9uIDMu MSwgbGFzdCBzZW50ZW5jZSBvZiBsaXN0IGl0ZW0gMy4xLiAKCiAgICAgICAgMi4gIFBhZ2UgMTcs IHRoaXJkIHBhcmFncmFwaCBvZiBsaXN0IGl0ZW0gNSwgc2VjdGlvbiAzLjEgCgogICAgICAgIDMu ICBQYWdlIDI0LCBlaWdodGggcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC4xIAoKICAgICAgICA0LiAg UGFnZSAzNiwgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC40LjEgCgoKICAgICAyLjE3LiBU cmFuc21pc3Npb24gb2YgREhDUE5BS3MgCgogICAgICAgIERIQ1BOQUtzIE1VU1QgYmUgYnJvYWRj YXN0IG9yIHVuaWNhc3QgdG8gYXQgdGhlIGxpbmsgbGV2ZWwgYmVjYXVzZSAKICAgICAgICB0aGUg Y2xpZW50IGhhcyBubyB2YWxpZCBJUCBhZGRyZXNzLiAgVGhlIHNhbWUgY29tbWVudCBhcHBsaWVz IHRvIAogICAgICAgIERIQ1BPRkZFUnMgYnV0IHdpdGggb25lIHNpZ25pZmljYW50IGRpZmZlcmVu Y2U6IGEgREhDUE9GRkVSIGhhcyBhIAogICAgICAgIHZhbGlkICJ5aWFkZHIiIHdoaWNoIGEgcmVs YXkgYWdlbnQgY2FuIHVzZSBhcyB0aGUgZGVzdGluYXRpb24gSVAgCiAgICAgICAgYWRkcmVzcy4g IEl0IGlzIG5vdCBjbGVhciB0aGF0IHdoYXRldmVyIG1lY2hhbmlzbSByZWxheSBhZ2VudHMgYXJl IAogICAgICAgIHVzaW5nIHRvIHRyYW5zbWl0IG9mZmVycyB3aWxsIHdvcmsgd2hlbiAieWlhZGRy IiBpcyAwLjAuMC4wLiAgCiAgICAgICAgVGhlcmVmb3JlLCBmb3Igc2FmZXR5knMgc2FrZSwgdGhl IHNlcnZlcnMgTVVTVCBzZXQgdGhlIGJyb2FkY2FzdCBiaXQgCiAgICAgICAgaW4gREhDUE5BSyBw YWNrZXRzLiAgVGhlIHRleHQgZGVzY3JpYmluZyBhIHNlcnZlcidzIGJlaGF2aW9yIHdoZW4gdGhl IAogICAgICAgIGNsaWVudCBpcyBhY2Nlc3NpYmxlIHRocm91Z2ggYSBCT09UUCByZWxheSBhZ2Vu dCBkb2VzIG5vdCBkbyB0aGlzOiAKCiAgICAgICAgMS4gIFBhZ2UgMTksIGxhc3QgcGFyYWdyYXBo IG9mIGxpc3QgaXRlbSAyLCBzZWN0aW9uIDMuMiAKCiAgICAgICAgMi4gIFBhZ2UgMjMsIGZpZnRo IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQuMSAKCiAgICAgICAgMy4gIFBhZ2UgMzIsIExhc3QgcGFy YWdyYXBoIG9mICJESENQUkVRVUVTVCBnZW5lcmF0ZWQgZHVyaW5nIElOSVQtCiAgICAgICAgICAg IFJFQk9PVCBzdGF0ZSwiIGJ1bGxldCwgc2VjdGlvbiA0LjMuMi4gCgogICAgICAgIFRoaXMgbGFz dCBkZXNjcmliZXMgdGhlIGJlaGF2aW9yIHRoYXQncyByZXF1aXJlZCAtLSBhIHNlcnZlciBNVVNU IHNldCAKICAgICAgICB0aGUgYnJvYWRjYXN0IGJpdCBpbiBvcmRlciBmb3IgdGhlIHJlbGF5IGFn ZW50IHRvIHByb3Blcmx5IGJyb2FkY2FzdCAKICAgICAgICB0aGUgREhDUE5BSy4gCgogICAgICAg IFJFQ09NTUVOREFUSU9OIAoKICAgICAgCiAgICAgSGliYnMgICAgICAgICAgICAgICAgRXhwaXJl czogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAgICAgICAgW1BhZ2UgMTldIAoKCgoKCgoKCgoKCiAg ICAgSW50ZXJuZXQgRHJhZnQgICAgICBSRkMgMjEzMSBJbXBsZW1lbnRhdGlvbiBJc3N1ZXMgICAg ICAgT2N0b2JlciAyMDAzIAogICAgICAKICAgICAgICBvICBJdGVtcyAoMSkgYW5kICgyKSBhYm92 ZSBzaG91bGQgZWl0aGVyIGR1cGxpY2F0ZSB0aGUgdGV4dCBvZiAKICAgICAgICAgICAoMyksIG9y IHNob3VsZCByZWZlcmVuY2Ugc2VjdGlvbiA0LjMuMi4gCgoKICAgICAyLjE4LiBVc2Ugb2YgY2lh ZGRyIAoKICAgICAgICBBY2NvcmRpbmcgdG8gUkZDIDk1MSBhbmQgUkZDIDE1NDIsIGNsaWVudHMg dXNlICJjaWFkZHIiIHdoZW4gdGhleSd2ZSAKICAgICAgICByZWNlaXZlZCBhbiBJUCBhZGRyZXNz IGZyb20gYSBzb3VyY2Ugb3V0c2lkZSBvZiBCT09UUC9ESENQLCBhbmQgY2FuIAogICAgICAgIHJl c3BvbmQgdG8gQVJQcy4gCgogICAgICAgIFRoZSB0ZXh0IGluIFJGQyAyMTMxIGlzIG1vc3RseSBz dXBwb3J0aXZlIG9mIHRoaXMgcG9pbnQgd2l0aCB0aGUgCiAgICAgICAgZm9sbG93aW5nIGV4Y2Vw dGlvbjogCgogICAgICAgICAgIFBhZ2UgMzIsICJESENQUkVRVUVTVCBnZW5lcmF0ZWQgZHVyaW5n IFJFQklORElORyBzdGF0ZToiIAogICAgICAgICAgIHNlY3Rpb24gNC4zLjI6ICAiVGhlIERIQ1Ag c2VydmVyIFNIT1VMRCBjaGVjayAnY2lhZGRyJyBmb3IgCiAgICAgICAgICAgY29ycmVjdG5lc3Mg YmVmb3JlIHJlcGx5aW5nIHRvIHRoZSBESENQUkVRVUVTVC4iIAoKICAgICAgICBUaGlzIGxpbmUg c2hvdWxkIGJlIHN0cnVjayBmcm9tIHRoZSBkb2N1bWVudC4gIFNlcnZlcnMgdHJ1c3QgCiAgICAg ICAgImNpYWRkciwiIHBlcmlvZC4gCgoKICAgICAyLjE5LiBTaXplIG9mIGEgQk9PVFAvREhDUCBm cmFtZSAKCiAgICAgICAgVGhlIGRlc2NyaXB0aW9uIGluIFJGQyAyMTMxIHJlbGF0aW5nIHRvIHRo ZSBzaXplIGNvbnN0cmFpbnRzIG9mIERIQ1AgCiAgICAgICAgcGFja2V0cyAoUGFnZSAxMCwgZmly c3QgcGFyYWdyYXBoIGFmdGVyIFRhYmxlIDEsIHNlY3Rpb24gMikgaXMgCiAgICAgICAgaW5hZGVx dWF0ZS4gCgoKICAgICAyLjE5LjEuIE1pbmltdW0gc2l6ZS4gCgogICAgICAgIFJGQyA5NTEgc3Rh dGVzIHRoYXQgYSBtaW5pbXVtIEJPT1RQIGZyYW1lIGlzIDMwMCBvY3RldHMgaW4gbGVuZ3RoLiAg CiAgICAgICAgU29tZSBCT09UUCByZWxheSBhZ2VudHMgaGF2ZSBiZWVuIGtub3duIHRvIGRyb3Ag ZnJhbWVzIG9mIGxlc3MgdGhhbiAKICAgICAgICAzMDAgb2N0ZXRzLiAgUkZDIDk1MSBpcyBleHBs aWNpdCBvbiB0aGlzIHBvaW50LCBidXQgUkZDIDIxMzEganVzdCAKICAgICAgICByZWZlcnMgdG8g UkZDIDk1MS4gIFNpbmNlIERIQ1AgaXMgaW50ZW5kZWQgdG8gYmUgYmFja3dhcmQgY29tcGF0aWJs ZSAKICAgICAgICB3aXRoIEJPT1RQLCB0aGUgcHJvdG9jb2wgc2hvdWxkIGNvbnRpbnVlIHRvIG9i c2VydmUgdGhpcyBsb3dlciBib3VuZC4gCgogICAgICAgIFJFQ09NTUVOREFUSU9OUzogCgogICAg ICAgIG8gIFRleHQgc2hvdWxkIGJlIGFkZGVkIHN0YXRpbmcgZXhwbGljaXRseSB0aGF0IHRoZSBt aW5pbXVtIHNpemUgCiAgICAgICAgICAgb2YgYSBESENQIGZyYW1lIGlzIDMwMCBvY3RldHMuIAoK CiAgICAgMi4xOS4yLiBNYXhpbXVtIFNpemUsIE1UVSwgYW5kIE1lc3NhZ2UgU2l6ZSBvcHRpb24g CgogICAgICAgIEl0IGhhcyBiZWVuIHRob3VnaHQgbmVjZXNzYXJ5IHRvIGF2b2lkIGZyYWdtZW50 YXRpb24gb2YgdGhlIElQIAogICAgICAgIHBhY2tldHMgaW4gREhDUC9CT09UUCBkdWUgdG8gY29u Y2VybnMgdGhhdCBzb21lIGNsaWVudHMgd291bGQgYmUgCiAgICAgICAgdW5hYmxlIHRvIHJlYXNz ZW1ibGUgZnJhZ21lbnRzIGJlZm9yZSB0aGUgSVAgc3RhY2sgaXMgcHJvcGVybHkgCiAgICAgICAg Y29uZmlndXJlZC4gIFJGQyA5NTEgc3RhdGVzICJGb3Igc2ltcGxpY2l0eSBpdCBpcyBhc3N1bWVk IHRoYXQgdGhlIAogICAgICAgIEJPT1RQIHBhY2tldCBpcyBuZXZlciBmcmFnbWVudGVkIi4gUmVn YXJkbGVzcyBvZiB0aGVvcmV0aWNhbCAKICAgICAgICBsaW1pdGF0aW9ucyBpbiBJUCBzdGFjayBp bXBsZW1lbnRhdGlvbnMsIGl0IGlzIGNlcnRhaW4gdGhhdCB0aGVyZSBhcmUgCiAgICAgIAogICAg IEhpYmJzICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAg ICAgIFtQYWdlIDIwXSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIx MzEgSW1wbGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAg ICAgc2V2ZXJhbCBESENQL0JPT1RQIGltcGxlbWVudGF0aW9ucywgYXQgYm90aCBlbmRzIG9mIHRo ZSBwcm90b2NvbCwgCiAgICAgICAgd2hpY2ggd2lsbCBub3QgcmVhc3NlbWJsZS4gCgogICAgICAg IFZhcmlvdXMgY29tbWVudHMgaW4gdGhlIFdPUktJTkcgR1JPVVAgaW1wbHkgdGhhdCBmcmFnbWVu dGF0aW9uIGNvdWxkIAogICAgICAgIGJlIGF2b2lkZWQgd2VyZSB0aGUgY2xpZW50IGNvbnNpc3Rl bnRseSB0byBpbmNsdWRlIHRoZSBNVFUgb2YgdGhlIAogICAgICAgIGxpbmsgbGF5ZXIgaW50ZXJm YWNlLiBCdXQgY2xpZW50cyBjYW5ub3QgYmUgZXhwZWN0ZWQgdG8gYmUgb21uaXNjaWVudCAKICAg ICAgICBhYm91dCBvdGhlciBtZWRpYSBvdmVyIHdoaWNoIHBhY2tldHMgdHJhdmVsIGVuIHJvdXRl IHRvIHNlcnZlcnMuICAKICAgICAgICBTZXJ2ZXJzIHRoYXQgbXVzdCBiZSBlbmRvd2VkIHdpdGgg dGhpcyBrbm93bGVkZ2UsIHdoaWNoIHRoZXkgTVVTVCB1c2UgCiAgICAgICAgdG8gYXZvaWQgcGFj a2V0IGZyYWdtZW50YXRpb24uIAoKICAgICAgICBPbmNlIHRoZSBJUCBzdGFjayBpcyBjb25maWd1 cmVkLCBhbmQgdGhlIElQIHN0YWNrIGlzIGZ1bGx5IAogICAgICAgIGNvbmZpZ3VyZWQsIHRoZSBh Zm9yZW1lbnRpb25lZCBsaW1pdGF0aW9uIGNlYXNlcyB0byBleGlzdCwgYW5kIGxhdGVyIAogICAg ICAgIHN0YWdlcyBvZiB0aGUgcHJvdG9jb2wgY291bGQgYWxsb3cgbGFyZ2VyIHBhY2tldHMgKHVw IHRvIHRoZSBVRFAgCiAgICAgICAgbGltaXQpLiAgREhDUElORk9STXMsIGVzcGVjaWFsbHksIGNv dWxkIGJlbmVmaXQgZnJvbSB0aGlzIHJlbGF4YXRpb24uICAKICAgICAgICBUaGVyZSBwcm9iYWJs eSBzaG91bGQgYmUgZXhwbGljaXQgdGV4dCB0byBhbGxvdyBsYXJnZXIgcGFja2V0cyAKICAgICAg ICAocHJlc3VtYWJseSB1cCB0byB0aGUgbWF4aW11bSBQRFUgc2l6ZSkgZm9yIGxhdGVyIHN0YWdl cyBvZiB0aGUgCiAgICAgICAgcHJvdG9jb2wuIAoKICAgICAgICBBIG51bWJlciBvZiBjbGllbnRz IHNlbmQgc21hbGwgcGFja2V0cyB3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgCiAgICAgICAgc2Vy dmVycyB3aWxsIG5vdCByZXR1cm4gYSBwYWNrZXQgdGhhdCBpcyBhbnkgbGFyZ2VyIHRoYW4gdGhl IG9uZSAKICAgICAgICByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuICBUaGUgY2xpZW50IE1VU1Qg Tk9UIG1ha2UgdGhpcyBhc3N1bXB0aW9uLiAKICAgICAgICBJZiB0aGUgY2xpZW50IGNhbm5vdCBw cm9jZXNzIGEgcmVzcG9uc2UgbGFyZ2VyIHRoYW4gYSBjZXJ0YWluIHNpemUsIAogICAgICAgIHRo ZSBjbGllbnQgTVVTVCB1c2UgdGhlIG1lc3NhZ2Ugc2l6ZSBvcHRpb24gdG8gaW5mb3JtIHNlcnZl cnMgb2YgdGhpcyAKICAgICAgICBzaXplLiBOb3RlIHRoYXQgdGhpcyBpcyBOT1QgdGhlIHNhbWUg b3B0aW9uIGFzIHRoZSBNVFUuIAoKICAgICAgICBSRUNPTU1FTkRBVElPTlM6IAoKICAgICAgICBv ICBTZXJ2ZXJzIGFuZCByZWxheSBhZ2VudHMgTVVTVCBlbnN1cmUgdGhhdCBJUCBkYXRhZ3JhbSAK ICAgICAgICAgICBmcmFnbWVudGF0aW9uIGRvZXMgbm90IG9jY3VyIGF0IGFueSBzdGFnZSBpbiB0 aGUgcHJvdG9jb2wgCiAgICAgICAgICAgYmVmb3JlIHRoZSBjbGllbnQgSVAgc3RhY2sgaXMgZnVs bHkgY29uZmlndXJlZC4gCgogICAgICAgIG8gIENsaWVudHMgU0hPVUxEIGNvbW11bmljYXRlIHRo ZWlyIGxpbmstbGF5ZXIgZnJhbWUgc2l6ZSB0byB0aGUgCiAgICAgICAgICAgREhDUCBzZXJ2ZXIg dmlhIHRoZSBESENQIE1UVSBvcHRpb24uIAoKICAgICAgICBvICBDbGllbnRzIE1VU1QgTk9UIGFz c3VtZSB0aGF0IHNlcnZlcnMgd2lsbCByZXR1cm4gYSBwYWNrZXQgbm8gCiAgICAgICAgICAgbGFy Z2VyIHRoYW4gdGhlIG9uZSB0aGV5IHNlbmQuIElmIHRoZSBjbGllbnQgaGFzIGEgbGltaXQgb24g dGhlIAogICAgICAgICAgIHNpemUgb2YgdGhlIHBhY2tldCB0aGF0IGl0IGNhbiBwcm9jZXNzIGl0 IE1VU1QgY29udmV5IHRoYXQgCiAgICAgICAgICAgbGltaXQgdG8gdGhlIHNlcnZlciBpbiB0aGUg Im1heGltdW0gbWVzc2FnZSBzaXplIiBvcHRpb24gKDU3KSAKCiAgICAgICAgbyAgUGFnZSAyMSwg c2Vjb25kIHBhcmFncmFwaCwgc2VjdGlvbiAzLjUsIHRoZSBmaXJzdCBzZW50ZW5jZSAKICAgICAg ICAgICBTSE9VTEQgYmUgY2hhbmdlZCB0byAiVGhlIGNsaWVudCBTSE9VTEQgaW5jbHVkZSB0aGUg J21heGltdW0gCiAgICAgICAgICAgREhDUCBtZXNzYWdlIHNpemUnIG9wdGlvbiB0byBsZXQgdGhl IHNlcnZlciBrbm93IGhvdyBsYXJnZSB0aGUgCiAgICAgICAgICAgc2VydmVyIG1heSBtYWtlIGl0 cyBESENQIG1lc3NhZ2VzLCBhbmQgdGhlIHZhbHVlIG9mIHRoaXMgb3B0aW9uIAogICAgICAgICAg IFNIT1VMRCBiZSB0aGUgTVRVIG9mIHRoZSBbY2xpZW50XSBuZXR3b3JrIGludGVyZmFjZSBiZWlu ZyAKICAgICAgICAgICBjb25maWd1cmVkLiIgCgogICAgICAgIG8gIFRoZSBXT1JLSU5HIEdST1VQ IFNIT1VMRCBjb25zaWRlciB3aGV0aGVyIHRvIGFsbG93IAogICAgICAgICAgIGZyYWdtZW50YXRp b24gb2YgcGFja2V0cyBhZnRlciB0aGUgY2xpZW50IGlzIGZ1bGx5IGNvbmZpZ3VyZWQsIAogICAg ICAgICAgIGFuZCBob3cgc2VydmVycyBjYW4gZGl2aW5lIHRoaXMgZmFjdCAoZS5nLiBhIG5vbi16 ZXJvIAogICAgICAgICAgICJjaWFkZHIiKS4gCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAg ICAgIEV4cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAgICAgIFtQYWdlIDIxXSAKCgoK CgoKCgoKCgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24g SXNzdWVzICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAgMi4yMC4gVXNlIG9mIGdpYWRk ciAKCiAgICAgICAgUGFnZSAyMywgZmlmdGggcGFyYWdyYXBoLCBzZWN0aW9uIDQuMTogICJJZiB0 aGUgJ2dpYWRkcpIgZmllbGQgaXMgCiAgICAgICAgemVybyBhbmQgdGhlICdjaWFkZHInIGZpZWxk IGlzIG5vbnplcm8sIHRoZW4gdGhlIHNlcnZlciB1bmljYXN0cyAKICAgICAgICBESENQT0ZGRVIg YW5kIERIQ1BBQ0sgbWVzc2FnZXMgdG8gdGhlIGFkZHJlc3MgaW4gJ2NpYWRkci4nIiAgVHJ1ZSBm b3IgCiAgICAgICAgREhDUEFDSywgZmFsc2UgZm9yIERIQ1BPRkZFUiAoYSBESENQRElTQ09WRVIg d2lsbCBuZXZlciBoYXZlIGFueXRoaW5nIAogICAgICAgIGJ1dCAwIGFzICJjaWFkZHIuIikgCgoK ICAgICAyLjIxLiBBZGRyZXNzIFNlbGVjdGlvbiAKCiAgICAgICAgUGFnZSAyNywgdGhpcmQgcGFy YWdyYXBoLCBzZWN0aW9uIDQuMy4xOiAgIk5vdGUgdGhhdCwgaW4gc29tZSBuZXR3b3JrIAogICAg ICAgIGFyY2hpdGVjdHVyZXMgKGUuZy4sIGludGVybmV0cyB3aXRoIG1vcmUgdGhhbiBvbiBJUCBz dWJuZXQgYXNzaWduZWQgCiAgICAgICAgdG8gYSBwaHlzaWNhbCBuZXR3b3JrIHNlZ21lbnQpLCBp dCBtYXkgYmUgdGhlIGNhc2UgdGhhdCB0aGUgREhDUCAKICAgICAgICBjbGllbnQgc2hvdWxkIGJl IGFzc2lnbmVkIGFuIGFkZHJlc3MgZnJvbSBhIGRpZmZlcmVudCBzdWJuZXQgdGhhbiB0aGUgCiAg ICAgICAgYWRkcmVzcyByZWNvcmRpbmcgaW4gJ2dpYWRkci4nIiAKCiAgICAgICAgVGhlcmUgYXJl IHR3byBkaWZmZXJpbmcgdmlldyBvZiB0aGlzIHNlbnRlbmNlOiAKCiAgICAgICAgICAgVGhlcmUg aXMgY29uc2lkZXJhYmxlIGRldGFpbCBpbiB0aGUgcmVzdCBvZiBSRkMgMjEzMSB0cnlpbmcgdG8g CiAgICAgICAgICAgZ2V0IHRoZSB1c2Ugb2YgImdpYWRkciIgY2xlYXIgYXMgaXQgcmVsYXRlcyB0 byBCT09UUCByZWxheSAKICAgICAgICAgICBhZ2VudHMgKFJGQyA5NTEgYW5kIFJGQyAxNTQyKSwg dGhlbiB0aGlzIHNlbnRlbmNlIGJhc2ljYWxseSAKICAgICAgICAgICAidW5kb2VzIiB0aGlzIHdv cmsuICBTZXJ2aW5nIG11bHRpcGxlIElQIG5ldHdvcmtzIG9uIHRoZSBzYW1lIAogICAgICAgICAg IHdpcmUgc2hvdWxkIGJlIGVpdGhlciBkZXNjcmliZWQgaW4gZGV0YWlsIGluIGl0cyBvd24gc2Vj dGlvbiAKICAgICAgICAgICAod2l0aCBjYXZlYXRzKSBvciBhcyBhIHNlcGFyYXRlIGluZm9ybWF0 aW9uYWwgUkZDLiAgT3RoZXJ3aXNlLCAKICAgICAgICAgICB0aGUgdXNlIG9mICJnaWFkZHIiIGlz IHVuY2xlYXIuIAoKICAgICAgICBBbHRlcm5hdGl2ZWx5OiAKCiAgICAgICAgICAgQWRkaXRpb25h bCBzdXBwb3J0aW5nIHRleHQgc2hvdWxkIGJlIGFkZGVkIHRvIFJGQyAyMTMxIHRvIHRoZSAKICAg ICAgICAgICBlZmZlY3QgdGhhdCBzZXJ2ZXJzIGhhdmluZyBrbm93bGVkZ2Ugb2YgbmV0d29yayB0 b3BvbG9neSBNQVkgCiAgICAgICAgICAgY2hvb3NlIHRvIG9mZmVyIGFuIGFkZHJlc3MgaW5jb25z aXN0ZW50IHdpdGggImdpYWRkciIgYnV0IAogICAgICAgICAgIGNvbnNpc3RlbnQgd2l0aCB0aGF0 IHRvcG9sb2d5LiAgRnVydGhlcm1vcmUsIHRoZSBhZGRyZXNzIAogICAgICAgICAgIG9mZmVyZWQg bWF5IGRpZmZlciBkZXBlbmRpbmcgdXBvbiB0aGUgY29udGVudHMgb2YgdGhlIHZlbmRvciAKICAg ICAgICAgICBjbGFzcywgdXNlciBjbGFzcywgYW5kIGV2ZW4gdGhlIGNsaWVudCBpZGVudGlmaWVy LiAgQWxsIG9mIAogICAgICAgICAgIHRoZXNlIHRoaW5ncyBhcmUgcG9saWN5IG1hdHRlcnMgZm9y IHRoZSBzZXJ2ZXIuIAoKCiAgICAgMi4yMi4gVXNlIG9mICJzZWNzIiBmaWVsZCAKCiAgICAgICAg VGhlICJzZWNzIiBmaWVsZCBoYXMgbm90IGJlZW4gZGlzY3Vzc2VkIG11Y2g6ICBtYW55IGNsaWVu dHMgc2ltcGx5IAogICAgICAgIGxlYXZlIGl0cyB2YWx1ZSBhcyB6ZXJvLCBhbmQgZmV3IGlmIGFu eSBzZXJ2ZXJzIGhhdmUgdXNlZCBpdHMgdmFsdWUgCiAgICAgICAgdG8gbW9kaWZ5IHRoZWlyIGJl aGF2aW9yLiBUaGVzZSBwcmFjdGljZXMgc2VlbSBhY2NlcHRhYmxlLiAgVGhlIHZhbHVlIAogICAg ICAgIG9mICJzZWNzIiBTSE9VTEQgYmUgdGhlIGVsYXBzZWQgdGltZSAoaW4gc2Vjb25kcykgc2lu Y2UgdGhlIGNsaWVudCAKICAgICAgICBiZWdhbiB0cnlpbmcgdG8gYWNxdWlyZSBvciBleHRlbmQg YSBsZWFzZSBvbiBhbiBJUCBhZGRyZXNzLiAgQSAKICAgICAgICBzaXh0ZWVuIGJpdCBmaWVsZCwg aXRzIG1heGltdW0gdmFsdWUgaXMgNjU1MzYuICBJdCBpcyBjb25jZWl2YWJsZSAKICAgICAgICB0 aGF0IGR1ZSB0byBzZXJ2ZXIgb3IgbmV0d29yayBmYWlsdXJlIHRoYXQgYSBjbGllbnQgbWF5IGhh dmUgYmVlbiAKICAgICAgICB3YWl0aW5nIGxvbmdlciB0aGFuIHRoaXMuIAoKICAgICAgICBSRUNP TU1FTkRBVElPTlM6IAogICAgICAKICAgICBIaWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBP Y3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICBbUGFnZSAyMl0gCgoKCgoKCgoKCgoKICAgICBJ bnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBP Y3RvYmVyIDIwMDMgCiAgICAgIAogICAgICAgIG8gIEEgY2xpZW50IE1BWSBjaG9vc2UgdG8gbGVh dmUgdG8gaWdub3JlIHRoZSBzZWNzIGZpZWxkLiAgSWYgc28gCiAgICAgICAgICAgaXRzIHZhbHVl IE1VU1QgYmUgc2V0IHRvIHplcm8uIElmIHRoZSBjbGllbnQgY2hvb3NlcyB0byBpbnNlcnQgCiAg ICAgICAgICAgYSB2YWx1ZSwgdGhlIHZhbHVlIFNIT1VMRCBiZSB0aW1lIGVsYXBzZWQgc2luY2Ug dGhlIGNsaWVudCAKICAgICAgICAgICBiZWdhbiBuZWdvdGlhdGluZyBmb3IgYW4gSVAgYWRkcmVz cy4gIElmIHRoZSBjbGllbnQgaGFzIGJlZW4gCiAgICAgICAgICAgd2FpdGluZyBsb25nZXIgdGhh biA2NTUzNiBzZWNvbmRzIGl0cyB2YWx1ZSBTSE9VTEQgYmUgNjU1MzYuICAKICAgICAgICAgICBU aGUgdmFsdWUgU0hPVUxEIE5PVCB3cmFwIGFyb3VuZCB0byB6ZXJvLiAKCgogICAgIDIuMjMuIFVz ZSBvZiAiaHR5cGUiIGFuZCAiaGxlbiIgZmllbGRzIAoKICAgICAgICBBdCBsZWFzdCBvbmUgdmVu ZG9yIGhhcyB1c2VkIGNoYWRkciBhcyBhIHBsYWNlIGhvbGRlciBmb3IgYSB2YWx1ZSAKICAgICAg ICB0aGF0IHdhcyBub3QgaW4gZmFjdCBhIGxpbmstbGF5ZXIgKGhhcmR3YXJlKSBhZGRyZXNzLCB3 aGlsZSBhdCB0aGUgCiAgICAgICAgc2FtZSB0eXBlIHVzaW5nIGFuIGh0eXBlIG9mIDEgKG1lYW50 IHRvIGJlIEV0aGVybmV0KSBidXQgYW4gaGxlbiBvZiAKICAgICAgICAxNiAoaW5zdGVhZCBvZiA2 KS4gIE1hbnkgc2VydmVycyB3aWxsIHJlamVjdCBhIHBhY2tldCB3aXRoIHRoaXMga2luZCAKICAg ICAgICBvZiBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIGh0eXBlIGFuZCBobGVuIGZpZWxkcy4g CgogICAgICAgIFZhbHVlcyBvZiBodHlwZSBub3QgZXF1YWwgdG8gemVybyBNVVNUIGNvcnJlc3Bv bmQgdG8gdGhlIGxpbmstbGV2ZWwgCiAgICAgICAgbWVkaXVtIHRvIHdoaWNoIHRoZSBESENQIGNs aWVudCBpcyBhdHRhY2hlZCBhY2NvcmRpbmcgdG8gSUFOQZJzIAogICAgICAgIEFzc2lnbmVkIE51 bWJlcnMgZGF0YWJhc2UuIAoKICAgICAgICBSRUNPTU1FTkRBVElPTlM6IAoKICAgICAgICBvICBU aGUgdmFsdWUgb2YgaGxlbiBNVVNUIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgbGVuZ3RoIG9mIGEg bGluay0KICAgICAgICAgICBsZXZlbCBhZGRyZXNzIGltcGxpZWQgYnkgaHR5cGUuIAoKICAgICAg ICBvICBBbiBodHlwZSBvZiB6ZXJvIFNIT1VMRCBiZSB1c2VkIHRvIG1lYW4gdGhhdCBjaGFkZHIg aXMgYW4gCiAgICAgICAgICAgaWRlbnRpZmllciB1bnJlbGF0ZWQgdG8gYSBzcGVjaWZpYyBsaW5r LWxldmVsIG1lZGl1bS4gCgoKICAgICAyLjI0LiBVc2Ugb2YgeGlkIGZpZWxkIAoKICAgICAgICBU aGlzIGZpZWxkIGV4aXN0cyB0byBhbGxvdyBjbGllbnRzIHRvIG1hdGNoIHJlcGxpZXMgdG8gcmVx dWVzdHMuICBJbiAKICAgICAgICB0d28gcGxhY2VzIFJGQyAyMTMxIGVycm9uZW91c2x5IHN0YXRl cyB0aGF0IHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGUgCiAgICAgICAgInhpZCIgaW4gdGhlIHNl cnZlcpJzIERIQ1BPRkZFUiBhcyB0aGUgdmFsdWUgaW4gaXRzIGZvbGxvdyB1cCByZXF1ZXN0IAoK ICAgICAgICBvICBUYWJsZSA1IERIQ1BSRVFVRVNUIGNvbHVtbiAKCiAgICAgICAgbyAgU2VjdGlv biA0LjQuMSBQYXJhIDUgCgogICAgICAgIEluIHByaW5jaXBsZSB0aGUgMzIgYml0cyBvZiAieGlk IiBzaG91bGQgYmUgc3VmZmljaWVudCB0byBtYWtlIHRoZSAKICAgICAgICBjaGFuY2Ugb2YgY29s bGlzaW9ucyBhbG1vc3QgbmlsLCBwcm92aWRlZCB0aGF0IGl0IGlzIHJhbmRvbWx5IAogICAgICAg IGdlbmVyYXRlZCBhcyAyMTMxIHN1Z2dlc3RzIGluIHNlY3Rpb24gNC40LjEgcGFyYWdyYXBoIDMu ICBIb3dldmVyLCAKICAgICAgICBzb21lIHZlbmRvcnMgaGF2ZSBhZG1pdHRlZCB0byBnZW5lcmF0 aW5nICJ4aWQiIHdoaWNoIG1heSBub3QgYmUgCiAgICAgICAgc3VmZmljaWVudGx5IHVuaWZvcm1s eSBkaXN0cmlidXRlZC4gCgogICAgICAgIFRoZSByYW5kb21uZXNzIHJlcXVpcmVtZW50IG9uICJ4 aWQiIGlzIG5vdCBhcyBzdHJpbmdlbnQgYXMgd291bGQgYmUgCiAgICAgICAgcmVxdWlyZWQsIHNh eSwgaW4gc2VsZWN0aW5nIGEgY3J5cHRvZ3JhcGhpYyBrZXkuICBJdCBpcyBxdWl0ZSAKICAgICAg ICBwZXJtaXNzaWJsZSB0aGF0IHRoZSBpbml0aWFsIGtleSBiZSBwcmVkaWN0YWJsZSBnaXZlbiBz dWZmaWNpZW50IAogICAgICAgIGtub3dsZWRnZSBvZiB0aGUgY2xpZW50LCBidXQgY2xpZW50cyBN VVNUIGVuc3VyZSB0aGF0IHRoZXNlIAogICAgICAgIGlkZW50aWZpZXJzIGFyZSBnZW5lcmF0ZWQg aW4gc3VjaCBhIHdheSB0aGF0IHRoZSBjaGFuY2Ugb2YgY29sbGlzaW9uIAogICAgICAKICAgICBI aWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAg ICBbUGFnZSAyM10gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMx IEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAgICAg IHdpdGggb3RoZXIgY2xpZW50cyBpbiB0aGUgREhDUCBhZG1pbmlzdHJhdGl2ZSBkb21haW4gaXMg d2hhdCBvbmUgCiAgICAgICAgc2hvdWxkIGV4cGVjdCBmcm9tIGEgdHJ1bHkgcmFuZG9tIG51bWJl ci4gCgogICAgICAgIFBlcm1pdHRpbmcgdGhlIHVzZSBvZiB0aGUgc2FtZSAieGlkIiBvbiBhIHJl LXRyYW5zbWlzc2lvbiBtaWdodCAKICAgICAgICBtYXJnaW5hbGx5IGltcHJvdmUgdGhlIGVmZmlj aWVuY3kgb2YgdGhlIHByb3RvY29sLiAgU2VydmVyIHJlc3BvbnNlcyAKICAgICAgICB0byB0aGUg Zmlyc3QgdHJhbnNtaXNzaW9uLCB3aGljaCBhcnJpdmVkIGFmdGVyIHRoZSB0aW1lb3V0IGFuZCAK ICAgICAgICByZXRyYW5zbWlzc2lvbiB3b3VsZCBiZSBhY2NlcHRlZCwgYW5kIG1pZ2h0IGF2b2lk IHlldCBhbm90aGVyIGNsaWVudCAKICAgICAgICB0aW1lb3V0LiAKCgogICAgIDIuMjUuIE9wdGlv bnMgaW4gREhDUE9GRkVSIGFuZCBESENQQUNLIAoKICAgICAgICBSRkMgMjEzMSBzYXlzIHRoYXQg dGhlIG9wdGlvbnMgZGVsaXZlcmVkIGluIHRoZXNlIHR3byBjYXNlcyBzaG91bGQgCiAgICAgICAg bm90IGJlIGluIGNvbmZsaWN0LiAgSXQgZG9lcyBub3Qgc2F5IHdoYXQgImNvbmZsaWN0IiBtZWFu cyBpbiB0aGF0IAogICAgICAgIGNhc2UuICBUaGlzIFNIT1VMRCBiZSBjbGFyaWZpZWQuIAoKICAg ICAgICBSRUNPTU1FTkRBVElPTlM6IAoKICAgICAgICBvICBTZXJ2ZXJzIE1BWSBkZWxpdmVyIGEg ZnVsbCBjb25maWd1cmF0aW9uIGluIGEgREhDUE9GRkVSLCBidXQgCiAgICAgICAgICAgYXJlIE5P VCByZXF1aXJlZCB0byBkbyBzby4gIFRoZSBESENQT0ZGRVIgTVVTVCBjb250YWluIGFuIElQIAog ICAgICAgICAgIGFkZHJlc3MgYW5kIGEgbGVhc2UgdGltZSwgYW5kIE1BWSBjb250YWluIG90aGVy IGluZm9ybWF0aW9uLiAgCiAgICAgICAgICAgQXMgYSBjbGllbnQgd2lsbCBwcmVzdW1hYmx5IGNo b29zZSBhbW9uZyBtdWx0aXBsZSBvZmZlcnMgYmFzZWQgCiAgICAgICAgICAgb24gc29tZSBjcml0 ZXJpYSwgcGVyaGFwcyBjb21wbGV0ZW5lc3Mgb2YgcmVzcG9uc2UsIHRoZSBzZXJ2ZXIgCiAgICAg ICAgICAgU0hPVUxEIGJlIHBlcm1pdHRlZCB0byByZXR1cm4gdGhlICdwYXJhbWV0ZXIgcmVxdWVz dCBsaXN0JyAKICAgICAgICAgICBpbmNsdWRpbmcgdGhlIG9wdGlvbiBjb2RlIGZvciBlYWNoIG9w dGlvbiBpdCBpcyBwcmVwYXJlZCB0byAKICAgICAgICAgICBkZWxpdmVyIGluIGEgREhDUEFDSyBt ZXNzYWdlLiAKCiAgICAgICAgbyAgSW4gYSBESENQQUNLIG1lc3NhZ2UsIHRoZSBsZWFzZSB0aW1l IG9mZmVyZWQgTVVTVCBiZSBhdCBsZWFzdCAKICAgICAgICAgICBhcyBsb25nIGFzIHRoYXQgaW4g dGhlIERIQ1BPRkZFUi4gIFRoZSBJUCBhZGRyZXNzIE1VU1QgYmUgdGhlIAogICAgICAgICAgIHNh bWUuIAoKICAgICAgICBvICBUaGUgb3B0aW9ucyBkZWxpdmVyZWQgaW4gYSBESENQQUNLIG1lc3Nh Z2UgTUFZIGRpZmZlciBmcm9tIAogICAgICAgICAgIHRob3NlIGluIGEgREhDUE9GRkVSLiAgU29t ZSBESENQIHNlcnZlcnMgYXR0ZW1wdCB0byBiYWxhbmNlIHRoZSAKICAgICAgICAgICBsb2FkIGZv ciBvdGhlciBzZXJ2aWNlcyBieSBwZXJtdXRpbmcgbGlzdHMuICBGb3IgaW5zdGFuY2UsIGEgCiAg ICAgICAgICAgc2VydmVyIGNvbmZpZ3VyZWQgd2l0aCAzIEROUyBzZXJ2ZXIgYWRkcmVzc2VzIG1h eSByb3RhdGUgdGhhdCAKICAgICAgICAgICBsaXN0IGVhY2ggdGltZSBhIGNsaWVudCBpcyBzZXJ2 aWNlZC4gIEl0IGlzIGEgcHJvYmxlbSBmb3Igc29tZSAKICAgICAgICAgICBzZXJ2ZXJzIHRvIGRl bGl2ZXIgYW4gaWRlbnRpY2FsIE9GRkVSIGFuZCBBQ0sgKGl0IGltcGxpZXMgCiAgICAgICAgICAg a2VlcGluZyBzdGF0ZS4pIAoKICAgICAgICBvICBJZiBhIHBhcnRpY3VsYXJseSBsb25nIG9wdGlv biBsaXN0IG11c3QgYmUgZGVsaXZlcmVkIHRvIHRoZSAKICAgICAgICAgICBjbGllbnQsIGl0IG1p Z2h0IG5vdCBiZSBwb3NzaWJsZSB0byBmaXQgYWxsIG9wdGlvbnMgaW4gdGhlIERIQ1AgCiAgICAg ICAgICAgcGF5bG9hZCBvZiBhIFVEUCBwYWNrZXQuICBSRkMgMjEzMSBhcHBlYXJzIHRvIHBlcm1p dCBhIGxvbmcgCiAgICAgICAgICAgbGlzdCBvZiBvcHRpb25zIHRvIGJlIHNlbnQgcGFydGx5IGlu IHRoZSBESENQT0ZGRVIgbWVzc2FnZSBhbmQgCiAgICAgICAgICAgcGFydGx5IGluIHRoZSBESENQ QUNLIG1lc3NhZ2UuIAoKCiAgICAgMi4yNi4gTGVhc2UgdGltZXMuIAoKICAgICAgICBSRkMgMjEz MSBoYXMgc29tZSBsYW5ndWFnZSAoc2VjdGlvbiA0LjMuMSkgdGhhdCBtaWdodCBiZSBpbnRlcnBy ZXRlZCAKICAgICAgICBhcyBjb25zdHJhaW5pbmcgdGhlIGR1cmF0aW9uIG9mIGEgbGVhc2UgdGhh dCBjYW4gYmUgb2ZmZXJlZCBiYXNlZCBvbiAKICAgICAgCiAgICAgSGliYnMgICAgICAgICAgICAg ICAgRXhwaXJlczogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAgICAgICAgW1BhZ2UgMjRdIAoKCgoK CgoKCgoKCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICBSRkMgMjEzMSBJbXBsZW1lbnRhdGlvbiBJ c3N1ZXMgICAgICAgT2N0b2JlciAyMDAzIAogICAgICAKICAgICAgICBwYXN0IGhpc3Rvcnkgb3Ig d2hhdCB0aGUgY2xpZW50IHdhbnRzLiAgVGhpcyBTSE9VTEQgYmUgcmV3cml0dGVuIHRvIAogICAg ICAgIG1ha2UgY2xlYXIgdGhhdCBpbiBhIERIQ1BPRkZFUiBhIHNlcnZlciBjYW4gb2ZmZXIgd2hh dGV2ZXIgbGVhc2UgdGltZSAKICAgICAgICB0aGF0IGxvY2FsIHBvbGljeSBmaW5kcyBhY2NlcHRh YmxlLCB3aXRob3V0IHJlZ2FyZCB0byB3aGF0IHRoZSBjbGllbnQgCiAgICAgICAgcmVxdWVzdHMs IG9yIHdoYXQgd2FzIG9mZmVyZWQgbGFzdCB0aW1lIGFyb3VuZC4gIElmIGEgc2VydmVyIG9mZmVy cyBhIAogICAgICAgIGxvbmdlciBsZWFzZSB0aGFuIHRoZSBjbGllbnQgcmVxdWVzdGVkLCB0aGUg Y2xpZW50IGNhbiBzaW1wbHkgZW50ZXIgCiAgICAgICAgdGhlIFJFTkVXSU5HIG9yIFJFQklORElO RyBzdGF0ZXMsIG9yIHNlbmQgYSBESENQUkVMRUFTRSBtZXNzYWdlIAogICAgICAgIGFjY29yZGlu ZyB0byBpdHMgZGVzaXJlZCBbZWFybGllcl0gdGltZXMuIAoKICAgICAgICBGb3IgUkVORVdBTFMs IHRoZSB0ZXh0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgc2VydmVycyBhcmUgbm90IAogICAg ICAgIG9ibGlnYXRlZCB0byBleHRlbmQgbGVhc2VzIG1lcmVseSBiZWNhdXNlIHRoZSBjbGllbnQg d2lzaGVzIGFuIAogICAgICAgIGV4dGVuc2lvbiBbc2VlIGFsc28gZ2VuZXJhbCBjb21tZW50IGJl bG93IGFib3V0IHBvbGljeS5dIAoKICAgICAgICBUaGVyZSBoYXMgc29tZXRpbWVzIGJlZW4gYW4g aXNzdWUgd2l0aCBUMSBhbmQgVDIgdGltZXMgYXMgZm9sbG93cy4gIAogICAgICAgIExldCdzIHNh eSB0aGF0IGEgbmV3IGxlYXNlIGlzIG9mZmVyZWQgd2l0aCBhIGNlcnRhaW4gVDAgKFQwIGlzIGxl YXNlIAogICAgICAgIGR1cmF0aW9uKSBhbmQgVDEgPSBUMC8yLiAgVGhlbiwgd2hlbiBUMSBleHBp cmVkLCB0aGUgY2xpZW50IGF0dGVtcHRzIAogICAgICAgIGEgcmVuZXdhbC4gIFRoZSBzZXJ2ZXIg aW4gcXVlc3Rpb24sIGZvciB3aGF0ZXZlciByZWFzb24sIGRvZXMgbm90IAogICAgICAgIHdhbnQg dG8gZXh0ZW5kIHRoZSBsZWFzZSwgYnV0IGlzIHdpbGxpbmcgdG8gY29uZmlybSB0aGUgcmVzaWR1 YWwgdGltZSAKICAgICAgICAoVDAvMikuICBJZiBpdCBhbHNvIHJldHVybnMgVDEgaW4gdGhlIG9w dGlvbnMsIGl0IHNob3VsZCBlbnN1cmUgdGhhdCAKICAgICAgICBUMSBpcyBhZGp1c3RlZCBmcm9t IHRoZSBvcmlnaW5hbCB2YWx1ZSBlbHNlIHRoZSBuZXcgQUNLIHdpbGwgaGF2ZSBUMCAKICAgICAg ICBhbmQgVDEgaWRlbnRpY2FsLiAKCgogICAgIDIuMjcuIE1pc2NlbGxhbmVvdXMgCgogICAgICAg IFRoZXJlIGFyZSBtYW55IFNIT1VMRHMgYW5kIFNIT1VMRCBOT1RzIHRoYXQgc2hvdWxkIHBlcmhh cHMgYmUgCiAgICAgICAgY29udmVydGVkIGludG8gTVVTVHMgb3IgTVVTVCBOT1RzLiAgSGVyZSBp cyBhIHN1bW1hcnk6ICAKCiAgICAgICAgMS4gIFBhZ2UgMTYsIGl0ZW0gNCwgc2VjdGlvbiAzLjEg IlRoZSBzZXJ2ZXIgU0hPVUxEIE5PVCBjaGVjayB0aGUgCiAgICAgICAgICAgIG9mZmVyZWQgbmV0 d29yayBhZGRyZXNzIGF0IHRoaXMgcG9pbnQuIiAgKE1VU1QgTk9UKSAKCiAgICAgICAgMi4gIFBh Z2UgMTYsIGl0ZW0gNSwgc2VjdGlvbiAzLjEgIlRoZSBjbGllbnQgU0hPVUxEIHBlcmZvcm0gYSAK ICAgICAgICAgICAgZmluYWwgY2hlY2sgb24gdGhlIHBhcmFtZXRlcnMuLi4iICAoTVVTVCkgCgog ICAgICAgIDMuICBQYWdlIDE3LCBpdGVtIDUsIHNlY3Rpb24gMy4xICJUaGUgY2xpZW50IFNIT1VM RCB3YWl0IGEgbWluaW11bSAKICAgICAgICAgICAgb2YgdGVuIHNlY29uZHMuLi4iICAoTVVTVCkg CgogICAgICAgIDQuICBQYWdlIDE4LCBpdGVtIDIsIHNlY3Rpb24gMy4yICJTZXJ2ZXJzIFNIT1VM RCBOT1QgY2hlY2sgdGhhdCAKICAgICAgICAgICAgdGhlIGNsaWVudCdzIG5ldHdvcmsgYWRkcmVz cyBpcyBhbHJlYWR5IGluIHVzZS4uLiIgIChNVVNUIE5PVCkgCgogICAgICAgIDUuICBQYWdlIDE5 LCBpdGVtIDIsIHNlY29uZCBwYXJhZ3JhcGgsIHNlY3Rpb24gMy4yICIuLi5zZXJ2ZXJzIAogICAg ICAgICAgICBTSE9VTEQgcmVzcG9uZCB3aXRoIGEgREhDUE5BSyBtZXNzYWdlIHRvIHRoZSBjbGll bnQiICAoTVVTVCkuICAKICAgICAgICAgICAgVGhlIGZvbGxvd2luZyBzZW50ZW5jZXMgYXJlIHJh dGhlciBkdWJpb3VzIGluIHRoaXMgcGFyYWdyYXBoIAogICAgICAgICAgICBhcyB3ZWxsLiAKCiAg ICAgICAgNi4gIFBhZ2UgMjEsIGZpcnN0IHBhcmFncmFwaCwgc2VjdGlvbiAzLjQgIlRoZSBzZXJ2 ZXJzIFNIT1VMRCAKICAgICAgICAgICAgdW5pY2FzdCB0aGUgREhDUEFDSyByZXBsYXkgdG8gdGhl IGFkZHJlc3MgZ2l2ZW4gaW4gdGhlIAogICAgICAgICAgICAnY2lhZGRyJyBmaWVsZCBvZiB0aGUg REhDUElORk9STSBtZXNzYWdlIiAgKE1VU1QpIAoKICAgICAgICA3LiAgUGFnZSAyMiwgbGFzdCBw YXJhZ3JhcGgsIHNlY3Rpb24gMy41ICJJZiBhIHNlcnZlciByZWNlaXZlcyBhIAogICAgICAgICAg ICBESENQIHJlcXVlc3QgbWVzc2FnZSB3aXRoIGFuIGludmFsaWQgJ3JlcXVlc3RlZCBJUCBhZGRy ZXNzJywgCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAgIEV4cGlyZXM6IE9jdCAyMDAz ICsgNiBtb250aHMgICAgICAgICAgIFtQYWdlIDI1XSAKCgoKCgoKCgoKCgogICAgIEludGVybmV0 IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNzdWVzICAgICAgIE9jdG9iZXIg MjAwMyAKICAgICAgCiAgICAgICAgICAgIHRoZSBzZXJ2ZXIgU0hPVUxEIHJlc3BvbmQgdG8gdGhl IGNsaWVudCB3aXRoIGEgREhDUE5BSyAKICAgICAgICAgICAgbWVzc2FnZS4uLiIgIChNVVNUKSAK CiAgICAgICAgUkVDT01NRU5EQVRJT05TOiAKCiAgICAgICAgbyAgVGhlIFdPUktJTkcgR1JPVVAg c2hvdWxkIHJldmlldyB0aGUgTUFZL1NIT1VMRC9NVVNUIChOT1QpcyBpbiAKICAgICAgICAgICBS RkMgMjEzMS4gVGhvc2UgU0hPVUxEcyB0aGF0IHJlbWFpbiBzaG91bGQgbGlzdCB0aGUgdmFsaWQg CiAgICAgICAgICAgZXhjZXB0aW9ucyAoc29tZSBkbzsgbW9zdCBkb24ndCkuIAoKCiAgICAgMy4g SW50ZWxsZWN0dWFsIFByb3BlcnR5IAoKICAgICAgICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlv biByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueSAKICAgICAgICBpbnRlbGxl Y3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0byAK ICAgICAgICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hu b2xvZ3kgZGVzY3JpYmVkIGluIAogICAgICAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0 byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyAKICAgICAgICBtaWdodCBvciBt aWdodCBub3QgYmUgYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQg CiAgICAgICAgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMu ICBJbmZvcm1hdGlvbiBvbiB0aGUgCiAgICAgICAgSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNw ZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFyZHMtdHJhY2sgYW5kIAogICAgICAgIHN0YW5kYXJkcy1y ZWxhdGVkIGRvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kIGluIEJDUC0xMS4gCgogICAgICAgIENv cGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxhYmxlIGZvciBwdWJsaWNhdGlvbiBh bmQgYW55IAogICAgICAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFi bGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gCiAgICAgICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBh IGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIAogICAgICAgIHN1 Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIAog ICAgICAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgU2VjcmV0 YXJpYXQuIAoKICAgICAgICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRv IGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55IAogICAgICAgIGNvcHlyaWdodHMsIHBhdGVudHMg b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkgCiAgICAgICAgcmln aHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gcHJh Y3RpY2UgCiAgICAgICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1h dGlvbiB0byB0aGUgSUVURiBFeGVjdXRpdmUgCiAgICAgICAgRGlyZWN0b3IuIAoKCiAgICAgNC4g Tm90ZXMgCgogICAgICAgIFRoaXMgc2VjdGlvbiB3aWxsIGJlIHJlbW92ZWQgd2hlbiB0aGlzIG1l bW8gZ29lcyB0byBXb3JraW5nIEdyb3VwIAogICAgICAgIExhc3QgQ2FsbC4gCgoKICAgICA0LjEu IElzc3VlcyAKCiAgICAgICAgT3BlbiwgdW5yZXNvbHZlZCBpc3N1ZXMgYWJvdXQgUkZDIDIxMzEg aW5jbHVkZTogCgogICAgICAgIDEuICBXaGF0IGlzIHRoZSBjb3JyZWN0IHVzZSBvZiBjbGllbnQg aWRlbnRpZmllciBpbiBESENQT0ZGRVIgYW5kIAogICAgICAgICAgICBESENQQUNLIG1lc3NhZ2Vz PyAKCiAgICAgICAgMi4gIEFyZSB0aGVyZSBhbnkgZWZmZWN0aXZlIGFsdGVybmF0aXZlcyB0byBJ Q01QIEVDSE8gYW5kIEFSUCBmb3IgCiAgICAgICAgICAgIGFkZHJlc3MtaW4tdXNlIGRldGVjdGlv bj8gCgogICAgICAKICAgICBIaWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyAr IDYgbW9udGhzICAgICAgICAgICBbUGFnZSAyNl0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBE cmFmdCAgICAgIFJGQyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIw MDMgCiAgICAgIAogICAgICAgIDMuICBXaGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgRnVsbHkg UXVhbGlmaWVkIERvbWFpbiBOYW1lPyAKCiAgICAgICAgNC4gIFNob3VsZCBESENQSU5GT1JNIG1l c3NhZ2VzIGJlIGFsbG93ZWQgZnJvbSBjbGllbnQgcHJveGllcz8gCgogICAgICAgIDUuICBTaG91 bGQgY2xpZW50IHByb3hpZXMsIGluIGdlbmVyYWwsIGJlIGFsbG93ZWQsIGFuZCBob3cgZG9lcyBh IAogICAgICAgICAgICBjbGllbnQgcHJveHkga25vdyB0aGUgSVAgYWRkcmVzcyBvZiBhIERIQ1Ag c2VydmVyPyAKCiAgICAgICAgNi4gIFNob3VsZCBhIERIQ1Agc2VydmVyIHNlbmQgb25seSBvcHRp b25zIHJlcXVlc3RlZCBieSBhIGNsaWVudCwgCiAgICAgICAgICAgIG9yIHNob3VsZCBhIHNlcnZl ciBzZW5kIGFsbCBvcHRpb25zIGZvciB3aGljaCBpdCBpcyBjb25maWd1cmVkIAogICAgICAgICAg ICB3aXRoIGEgdmFsdWU/IAoKICAgICAgICA3LiAgU2hvdWxkIHJlcXVpcmVkIHVzYWdlIG9mICJ4 aWQiIGFuZCAiY2xpZW50IGlkZW50aWZpZXIiIGJlIAogICAgICAgICAgICBjaGFuZ2VkIHRvIHN1 cHBvcnQgc2VydmVyIHZlcmlmaWNhdGlvbiBvZiBESENQUkVMRUFTRSAKICAgICAgICAgICAgbWVz c2FnZXM/IAoKICAgICAgICA4LiAgV2hhdCBpcyB0aGUgY29ycmVjdCBzdGF0ZW1lbnQgYWJvdXQg c2VsZWN0aW5nIGFuIElQIGFkZHJlc3MgdG8gCiAgICAgICAgICAgIG9mZmVyIGEgY2xpZW50IHdo ZW4gdGhlIG9mZmVyZWQgYWRkcmVzcyBpcyBvbiBhIGRpZmZlcmVudCAKICAgICAgICAgICAgc3Vi bmV0IHRoYW4gdGhlIGNsaWVudCdzICJnaWFkZHI/IiAKCiAgICAgICAgOS4gIFNob3VsZCBhIG5l dyBmbGFncyBiaXQgdG8gc2lnbmlmeSAibW9yZSBvcHRpb25zIGRhdGEgCiAgICAgICAgICAgIGF2 YWlsYWJsZSIgYmUgYWRkZWQ/IAoKICAgICAgICAxMC4gRG8gd2UgbmVlZCBhIG5ldyAiTWF4aW11 bSBSZWxheSBNVFUgU2l6ZSIgb3B0aW9uIHRvIGVuc3VyZSAKICAgICAgICAgICAgdGhhdCBhbGwg cmVwbHkgcGFja2V0cyBzZW50IGJ5IGEgc2VydmVyIHdpbGwgcGFzcyB3aXRob3V0IAogICAgICAg ICAgICBmcmFnbWVudGluZyBvciBkcm9wcGluZyBwYWNrZXRzPyAKCiAgICAgICAgMTEuIFdvdWxk IGl0IGhlbHAgdG8gc2V0IGEgc29ydCBvZiAibW9yZSB0byBjb21lIiBvcHRpb24sIAogICAgICAg ICAgICBpbmRpY2F0aW5nIHRoYXQgbW9yZSBvcHRpb25zIHdpbGwgZm9sbG93IGluIGEgY29uc2Vj dXRpdmUgCiAgICAgICAgICAgIERIQ1BBQ0ssIHdoZXJlIHRoZSBzdWJzZXF1ZW50IERIQ1BBQ0tz IHdvdWxkIGhhdmUgYSAKICAgICAgICAgICAgImFkZGl0aW9uYWwgaW5mb3JtYXRpb24iIG9wdGlv biBpbmRpY2F0aW5nIHRoYXQgdGhlIG1lc3NhZ2UgCiAgICAgICAgICAgIGNvbnRhaW5zIG9ubHkg bmV3IG9wdGlvbnMgZGF0YSBzaW1pbGFyIHRvIGEgREhDUEFDSyBpbiAKICAgICAgICAgICAgcmVz cG9uc2UgdG8gYSBESENQSU5GT1JNIG1lc3NhZ2U/IAoKICAgICAgICAxMi4gQXJlIHVuaWNhc3Qg REhDUERJU0NPVkVSIG1lc3NhZ2VzIHBlcm1pdHRlZD8gIFdoYXQgYXJlIHRoZSAKICAgICAgICAg ICAgcmVxdWlyZW1lbnRzIGZvciBzcGVjaWZpYyBtZXNzYWdlIGZpZWxkcyBhbmQgb3B0aW9ucyBp biB0aGlzIAogICAgICAgICAgICBjYXNlPyAKCiAgICAgICAgMTMuIFdoYXQgbGV2ZWwgb2YgY29u c2lzdGVuY3kgaXMgcmVxdWlyZWQgYW1vbmcgcmVzcG9uc2VzIGZyb20gCiAgICAgICAgICAgIG11 bHRpcGxlIHNlcnZlcnM/IAoKCiAgICAgNC4yLiBDaGFuZ2VzIGZyb20gUHJpb3IgRHJhZnRzIAoK ICAgICAgICBUaGUgIi0wMSIgcmV2aXNpb24gY29udGFpbnMgc3Vic3RhbnRpYWwgY2hhbmdlcyBm b2xsb3dpbmcgYSBkZXRhaWxlZCAKICAgICAgICByZXZpZXcgb2YgREhDIFdvcmtpbmcgR3JvdXAg bWFpbGluZyBsaXN0IGRpc2N1c3Npb25zIG9uIFJGQyAyMTMxIAogICAgICAgIGNsYXJpZmljYXRp b24gaXNzdWVzLCBjb25zaWRlcmF0aW9uIG9mIHNldmVyYWwgZGlyZWN0ZWQgcXVlc3Rpb25zLCAK ICAgICAgICBhbmQgY29tbWVudHMgcmVjZWl2ZWQgYnkgdGhlIGF1dGhvcnMuICBDaGFuZ2VzIGlu Y2x1ZGU6IAoKICAgICAgICBvICBSZW9yZ2FuaXphdGlvbiBvZiB0aGUgZG9jdW1lbnQgdG8gZ3Jv dXAgYWxsIHR5cG9ncmFwaGljYWwgCiAgICAgICAgICAgZXJyb3JzIHRvZ2V0aGVyLCBzZXBhcmF0 ZSBmcm9tIHByb3RvY29sIG9yIHBvbGljeSBpc3N1ZXMuIAogICAgICAKICAgICBIaWJicyAgICAg ICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICBbUGFnZSAy N10gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBEcmFmdCAgICAgIFJGQyAyMTMxIEltcGxlbWVu dGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIwMDMgCiAgICAgIAogICAgICAgIG8gIEVsaW1p bmF0aW9uIG9mICJJbnRlcmFjdGlvbiB3aXRoIEROUyIgYW5kICJDbGllbnQgYW5kIFNlcnZlciAK ICAgICAgICAgICBBZG1pbmlzdHJhdGlvbiIgc2VjdGlvbnMgYmVjYXVzZSB0aGUgYXV0aG9ycyBz YXcgbm8gY2xlYXIgCiAgICAgICAgICAgcmVzb2x1dGlvbiB0byB0aGUgdG9waWNzLiAKCiAgICAg ICAgbyAgQ3JlYXRpb24gb2YgYW4gaXNzdWVzIGxpc3QgaW4gc2VjdGlvbiA0LjEuIAoKICAgICAg ICBUaGUgIi0wMCIgcmV2aXNpb24gd2FzIHRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhpcyBtZW1v LCBzdWJtaXR0ZWQgdG8gCiAgICAgICAgdGhlIEludGVybmV0LURyYWZ0cyBlZGl0b3Igb24gMjMg RmVicnVhcnkgMjAwMy4gCgoKICAgICA1LiBBY2tub3dsZWRnZW1lbnRzIAoKICAgICAgICBUaGlz IGRvY3VtZW50IGlzIHRoZSByZXN1bHQgb2Ygd29yayB1bmRlcnRha2VuIHRoZSBieSBESENQIHdv cmtpbmcgCiAgICAgICAgZ3JvdXAuICBUaGUgZWRpdG9ycyB3b3VsZCBsaWtlIHRvIGluY2x1ZGUg YSBudW1iZXIgb2YgY29udHJpYnV0b3JzIHRvIAogICAgICAgIHRoaXMgZWZmb3J0IGluY2x1ZGlu ZyBNaWtlIENhcm5leSBvZiBTdW4gTWljcm9zeXN0ZW1zLCBTdGV2ZSBUdWxsb2ggCiAgICAgICAg b2YgU2hhZG93IFN1cHBvcnQsIEJlcm5pZSBWb2x6LCBUZWQgTGVtb24gb2YgTm9taW51bSwgU2lt b24gVm9nbCwgCiAgICAgICAgRWR3YXJkIE1hc2NhcmVuaGFzIG9mIFNHSSwgQW5kcmUgS29zdHVy IG9mIEluY29nbml0bywgQnVkIE1pbGx3b29kIG9mIAogICAgICAgIFdlaXJkIFNvbHV0aW9ucywg UGF0cmljayBHdelsYXQgb2YgSW1wcm9XYXJlIE5ldHdvcmsgU2VydmljZXMsIGFuZCAKICAgICAg ICBTd2FteSBOYXJhc2ltaGEgb2YgTm9raWEuIAoKCiAgICAgNi4gSUFOQSBDb25zaWRlcmF0aW9u cyAKCiAgICAgICAgVGhpcyBtZW1vIGNvbnRhaW5zIG5vIHZhbHVlcyByZXF1aXJpbmcgSUFOQSBh dHRlbnRpb24uIAoKCiAgICAgNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgCgogICAgICAgIChU byBiZSBkZWZpbmVkIHdoZW4gc3VnZ2VzdGVkIHRleHQgY2hhbmdlcyBmb3IgUkZDIDIxMzEgYXJl IAogICAgICAgIGNvbXBsZXRlZC4pIAoKICAgICAgICBBIHNlcGFyYXRlIEludGVybmV0LURyYWZ0 IGlzIGJlaW5nIGNyZWF0ZWQgdG8gcHJvdmlkZSBhIGNvbXBsZXRlIAogICAgICAgIHRocmVhdCBh bmFseXNpcyBvZiBSRkNzIDIxMzEgYW5kIDMxMTguIAoKCiAgICAgOC4gUmVmZXJlbmNlcyAKCiAg ICAgW1JGQzk1MV0gQ3JvZnQsIFcuLCBhbmQgR2lsbW9yZSwgSi4sICJCb290c3RyYXAgUHJvdG9j b2wsIiBSRkMgOTUxLCAKICAgICAgICBTZXB0ZW1iZXIgMTk4NS4gCgogICAgIFtSRkMxMTIzXSBS LiBCcmFkZW4sICJSZXF1aXJlbWVudHMgZm9yIEludGVybmV0IEhvc3RzIC0tIEFwcGxpY2F0aW9u IAogICAgICAgIGFuZCBTdXBwb3J0LCIgT2N0b2JlciAxOTg5LiAKCiAgICAgW1JGQzE1NDJdIFcu IFdpbWVyLCAiQ2xhcmlmaWNhdGlvbnMgYW5kIEV4dGVuc2lvbnMgZm9yIHRoZSBCb290c3RyYXAg CiAgICAgICAgUHJvdG9jb2wiIFJGQyAxNTQyLCBPY3RvYmVyIDE5OTMgCgogICAgIFtSRkMyMTMx XSBEcm9tcywgUi4sICJEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCwiIE1hcmNo IDE5OTcuIAoKICAgICBbUkZDMjEzMl0gQWxleGFuZGVyLCBTLiBhbmQgRHJvbXMsIFIuLCAiREhD UCBPcHRpb25zIGFuZCBCT09UUCBWZW5kb3IgCiAgICAgICAgRXh0ZW5zaW9ucywiIE1hcmNoIDE5 OTcuIAogICAgICAKICAgICBIaWJicyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyAr IDYgbW9udGhzICAgICAgICAgICBbUGFnZSAyOF0gCgoKCgoKCgoKCgoKICAgICBJbnRlcm5ldCBE cmFmdCAgICAgIFJGQyAyMTMxIEltcGxlbWVudGF0aW9uIElzc3VlcyAgICAgICBPY3RvYmVyIDIw MDMgCiAgICAgIAogICAgIFtSRkMzMjAzXSBUJ0pvZW5zLCBZLiwgSHVibGV0LCBDLiwgYW5kIERl IFNjaHJpanZlciwgUC4sICJUaGUgREhDUCAKICAgICAgICBSZWNvbmZpZ3VyZSBFeHRlbnNpb24s IiBKdWx5IDIwMDEuIAoKICAgICA8ZHJhZnQtaWV0Zi1kaGMtbGVhc2VxdWVyeS0wNS50eHQ+IFdv dW5keSwgUi4sIGFuZCBLaW5uZWFyLCBLLiwgIkRIQ1AgCiAgICAgICAgTGVhc2UgUXVlcnksIiBN YXJjaCAyMDAzLiAKCiAgICAgPGRyYWZ0LWlldGYtZGhjLWZxZG4tb3B0aW9uLTA1LnR4dD4sIFN0 YXBwLCBNLiwgYW5kIFJla2h0ZXIsIFkuLCAiVGhlIAogICAgICAgIERIQ1AgQ2xpZW50IEZRRE4g T3B0aW9uLCIgTm92ZW1iZXIgMjAwMi4gCgogICAgIDxkcmFmdC1zd2FteS1kaGMtY2xpZW50LWlk LTAwLnR4dD4sIE5hcmFzaW1oYSwgUy4sICJDbGllbnQgSWRlbnRpZmllciAKICAgICAgICBvcHRp b24gaW4gc2VydmVyIHJlcGxpZXMsIiBKdWx5IDIwMDMuIAoKCiAgICAgOS4gRWRpdG9ycycgQWRk cmVzc2VzIAoKICAgICAgICBSaWNoYXJkIEJhcnIgSGliYnMgCiAgICAgICAgOTUyIFNhbmNoZXog U3RyZWV0IAogICAgICAgIFNhbiBGcmFuY2lzY28sIENhbGlmb3JuaWEgOTQxMTQtMzM2MiAKICAg ICAgICBVU0EgCgogICAgICAgIFBob25lOiAgKzEtKDQxNSktNjQ4LTM5MjAgCiAgICAgICAgRW1h aWw6ICByYmhpYmJzQHBhY2JlbGwubmV0IAoKICAgICAgICBSb2IgU3RldmVucyAKICAgICAgICAz MDggQXJ0aHVyIEF2ZSAKICAgICAgICBBcHRvcyBDYWxpZm9ybmlhIDk1MDAzLTUyMDIgCiAgICAg ICAgVVNBIAoKICAgICAgICBQaG9uZTorMS0oODMxKS02ODgtOTcyMiAKICAgICAgICBFLW1haWw6 ICByb2JzQGNydXppby5jb20gCgoKICAgICAxMC4gRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IAoK ICAgICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5LCAyMDAzLiAgQWxsIFJp Z2h0cyBSZXNlcnZlZC4gCgogICAgICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBv ZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8gCiAgICAgICAgb3RoZXJzLCBhbmQg ZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQg CiAgICAgICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQs IGNvcGllZCwgcHVibGlzaGVkIAogICAgICAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3Ig aW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkgCiAgICAgICAga2luZCwgcHJvdmlk ZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJl IAogICAgICAgIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jr cy4gSG93ZXZlciwgdGhpcyAKICAgICAgICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2Rp ZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nIAogICAgICAgIHRoZSBjb3B5cmln aHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIg CiAgICAgICAgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhl IHB1cnBvc2Ugb2YgCiAgICAgICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp Y2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgCiAgICAgICAgY29weXJpZ2h0cyBkZWZpbmVkIGlu IHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIAogICAgICAgIGZvbGxvd2Vk LCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhh biAKICAgICAgICBFbmdsaXNoLiAKCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAgIEV4 cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAgICAgIFtQYWdlIDI5XSAKCgoKCgoKCgoK CgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNzdWVz ICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAgICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lv bnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZSAKICAgICAgICBy ZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2ln bnMuIAoKICAgICAgICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbiAKICAgICAgICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg SU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIAogICAgICAgIFRB U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORyAKICAgICAgICBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhF IFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gCiAgICAgICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdF IEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiAKICAgICAgICBNRVJDSEFO VEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIAoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAgICAgIAogICAgIEhpYmJzICAgICAgICAg ICAgICAgIEV4cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAgICAgIFtQYWdlIDMwXSAK CgoKCgoKCgoKCgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRp b24gSXNzdWVzICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAgQVBQRU5ESVggQTogIExp c3Qgb2YgVmVuZG9ycyAKCiAgICAgIAogICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAKICAgICB8VmVuZG9y ICAgICAgICAgICAgfFByb2R1Y3QgICAgICAgICAgfEUtbWFpbCBBZGRyZXNzICAgICAgICAgICAg ICAgICAgIHwgCiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIAogICAgIHwyV2lyZSAgICAgICAgICAgICB8 SG9tZVBvcnRhbCAgICAgICB8c3VwcG9ydEAyV2lyZS5jb20gICAgICAgICAgICAgICAgfCAKICAg ICB8M0NvbSAgICAgICAgICAgICAgfEhvbWUgR2F0ZXdheSAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgCiAgICAgfDNlIFRlY2hub2xvZ2llcyAgIHwgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHwgSW50ZXJuYXRp b25hbCAgICB8TWFnbnVtICAgICAgICAgICB8aW5mb0AzZXRpLmNvbSAgICAgICAgICAgICAgICAg ICAgfCAKICAgICB8M0sgR3JvdXAgICAgICAgICAgfFR1cmJvIENlbGwgICAgICAgfGluZm9AM2tn cm91cC5jb20gICAgICAgICAgICAgICAgIHwgCiAgICAgfEFjY2VsZXJhdGVkICAgICAgIHwgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHwg VGVjaG5vbG9neSAgICAgICB8TnVjbGV1cyAgICAgICAgICB8c3VwcG9ydEBhY2NlbGVyYXRlZHRl Y2hub2xvZ3kuY29tfCAKICAgICB8QWN0aW9uVGVjICAgICAgICAgfCAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfCBFbGVjdHJvbmljcyAg ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 IAogICAgIHxBRFRSQU4gICAgICAgICAgICB8TmV0dmFudGEgMjEwMCAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8QWdlcmUgU3lzdGVtcyAgICAgfE9yaW5vY28g UkctMTAwMCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfEFwcGxl IENvbXB1dGVyICAgIHwgICAgICAgICAgICAgICAgIHxjaGVzaGlyZUBhcHBsZS5jb20gICAgICAg ICAgICAgICB8IAogICAgIHxBcHBsaWFuc3lzICAgICAgICB8RE5TQm94IDMwMCAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8QXJndXMgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAg ICAgfCBUZWNobm9sb2dpZXMgICAgIHxFdGhlckFjY2VzcyAyMDAwIHxpbmZvQGFyZ3VzY29ycC5j b20gICAgICAgICAgICAgICB8IAogICAgIHxBdGVvbml4IE5ldHdvcmtzICB8TkFTQVMtMjA0MCAg ICAgICB8dGVjaEBhdGVvbml4LmNvbSAgICAgICAgICAgICAgICAgfCAKICAgICB8QXZheWEgICAg ICAgICAgICAgfFdBUCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgCiAgICAgfEJhcmJlZCBXaXJlICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHwgVGVjaG5vbG9naWVzICAgICB8ICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8 QnJvYWRiYW5kICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgCiAgICAgfCBHYXRld2F5cyAgICAgICAgIHxFdm9sbyAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxDYWxkZXJhL1NDTyAg ICAgICB8T3BlbiBMaW51eCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAKICAgICB8ICAgICAgICAgICAgICAgICAgfCAgIEVzZXJ2ZXIgICAgICAgfGluZm9Ac2NvLmNv bSAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfENheW1hbiBTeXN0ZW1zICAgIHwgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxDaGVj a1BvaW50ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAKICAgICB8ICAgU29mdHdhcmUgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfENpc2NvIFN5c3RlbXMgICAg IHxOZXR3b3JrICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAog ICAgIHwgICAgICAgICAgICAgICAgICB8UmVnaXN0cmFyICAgICAgICB8a2tpbm5lYXJAY2lzY28u Y29tICAgICAgICAgICAgICAgfCAKICAgICB8Q2lzY28gU3lzdGVtcyAgICAgfEFJUi1BUDMwMDAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfENsYXZpc3Rl ciAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IAogICAgIHxDTGludXggICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8Q29tcGFxICAgICAgICAgICAgfENv bm5lY3Rpb24gUG9pbnQgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAg fHZDb05ldCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IAogICAgIHwgICBDb21tdW5pY2F0aW9ucyB8WHByZXNzSVAgODU1MCAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8Q3lnc29mdCAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfHN1cHBvcnRAY3lnc29mdC5jb20gICAgICAgICAgICAg IHwgCiAgICAgfEQtTGluayAgICAgICAgICAgIHxESS03MDAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxFZmZpY2llbnQgICAgICAgICB8ICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8ICAg TmV0d29ya3MgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgCiAgICAgfEVzb2Z0ICAgICAgICAgICAgIHxSZWRwaGlzaCAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxGaWxhbmV0ICAgICAgICAg ICB8SW50ZXJqYWsgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAK ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gCgoKCiAgICAgIAogICAgIEhpYmJzICAgICAgICAgICAgICAg IEV4cGlyZXM6IE9jdCAyMDAzICsgNiBtb250aHMgICAgICAgICAgIFtQYWdlIDMxXSAKCgoKCgoK CgoKCgogICAgIEludGVybmV0IERyYWZ0ICAgICAgUkZDIDIxMzEgSW1wbGVtZW50YXRpb24gSXNz dWVzICAgICAgIE9jdG9iZXIgMjAwMyAKICAgICAgCiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIAogICAg IHxWZW5kb3IgICAgICAgICAgICB8UHJvZHVjdCAgICAgICAgICB8RS1tYWlsIEFkZHJlc3MgICAg ICAgICAgICAgICAgICAgfCAKICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gCiAgICAgfEZUUCBTb2Z0d2Fy ZSAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IAogICAgIHxIZWxpb3MgICAgICAgICAgICB8UENTaGFyZSAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8SW5jb2duaXRvICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfCAg IFNvZnR3YXJlICAgICAgIHxBZGRyZXNzIENvbW1hbmRlcnxzdXBwb3J0QGluY29nbml0by5jb20g ICAgICAgICAgICB8IAogICAgIHxJbmZvQmxveCAgICAgICAgICB8RE5TIE9uZSAgICAgICAgICB8 c3VwcG9ydEBpbmZvYmxveC5jb20gICAgICAgICAgICAgfCAKICAgICB8SW50ZXJuZXQgU29mdHdh cmUgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg CiAgICAgfCAgIENvbnNvcnRpdW0gICAgIHxESENQRCAgICAgICAgICAgIHxUZWQuTGVtb25Abm9t aW51bS5jb20gICAgICAgICAgICB8IAogICAgIHxBdHRhY2hOZXQgICAgICAgICB8SW50ZXJuZXQg UHJvIFNPSE98c3VwcG9ydEBhdHRhY2huZXQuY29tICAgICAgICAgICAgfCAKICAgICB8SW50ZXJO aWNoZSAgICAgICAgfFBvcnRhYmxlIERIQ1AgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgCiAgICAgfCAgIFRlY2hvbG9naWVzICAgIHxTZXJ2ZXIgICAgICAgICAgIHxzdXBw b3J0QGluaWNoZS5jb20gICAgICAgICAgICAgICB8IAogICAgIHxKSCBTb2Z0d2FyZSAgICAgICB8 U2ltcGxlIEROU1BsdXMgICB8c3VwcG9ydEBqaHNvZnQuY29tICAgICAgICAgICAgICAgfCAKICAg ICB8TGV2aXRvbiAgICAgICAgICAgfEludGVybmV0IEdhdGV3YXkgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgCiAgICAgfExpZ2h0bmluZyAgICAgICAgIHxNdWx0aUNPTSAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxMaW5rU3lzICAg ICAgICAgICB8V0FQLTExICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAKICAgICB8THVjZW50ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfCAgIFRlY2hub2xvZ2llcyAgIHxWaXRh bFFJUCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxN YXRyb3ggRWxlY3Ryb25pYyB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAKICAgICB8ICAgU3lzdGVtcyAgICAgICAgfGlTd2l0Y2ggICAgICAgICAg fG5ldHdvcmtzLnRlY2hzdXBwb3J0QG1hdHJveC5jb20gIHwgCiAgICAgfFVNYXggVGVjaG5vbG9n aWVzIHxVR2F0ZS0zMzAwICAgICAgIHxzdXBwb3J0QHVtYXhjYXJlLmNvbSAgICAgICAgICAgICB8 IAogICAgIHxNREwgQ29ycG9yYXRpb24gICB8RmlsZVplcnZlciBOQVMgICB8aGVscEBtZGxjb3Jw LmNvbSAgICAgICAgICAgICAgICAgfCAKICAgICB8TWljcm9zb2Z0ICAgICAgICAgfCAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfCAgIENv cnBvcmF0aW9uICAgIHxXaW5kb3dzIFNlcnZlciAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IAogICAgIHxNb2JpV2F2ZSAgICAgICAgICB8U3B5cm96ICAgICAgICAgICB8c3Vw cG9ydEBtb2Jpd2F2ZS5jb20gICAgICAgICAgICAgfCAKICAgICB8TXVsdGktVGVjaCAgICAgICAg fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAg ICAgfCAgIFN5c3RlbXMgICAgICAgIHxSb3V0ZUZpbmRlciBWUE4gIHxzdXBwb3J0QG11bHRpdGVj aC5jb20gICAgICAgICAgICB8IAogICAgIHxOM0sgICAgICAgICAgICAgICB8Vml0YWxRSVAgICAg ICAgICB8aW5mb0BuM2suY28udWsgICAgICAgICAgICAgICAgICAgfCAKICAgICB8TmV0IEludGVn cmF0aW9uICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgCiAgICAgfCAgIFRlY2hub2xvZ2llcyAgIHxOZXQgSW50ZWdyYXRvciAgIHxzdXBwb3J0 QG5ldC1pdGVjaC5jb20gICAgICAgICAgICB8IAogICAgIHxOZXRnZWFyICAgICAgICAgICB8UlAz MzQgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8 TmV0V2luZGVyICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgCiAgICAgfE5ldHdvcmsgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHwgICBUZWxlU3lzdGVt cyAgICB8ICAgICAgICAgICAgICAgICB8c3VwcHBvcnRAc2hhZG93c3VwcG9ydC5jb20gICAgICAg fCAKICAgICB8Tm9raWEgICAgICAgICAgICAgfElQMzAgICAgICAgICAgICAgfGludGVybmV0YXBh Y0Bub2tpYS5jb20gICAgICAgICAgIHwgCiAgICAgfE5vbWludW0sIEluYy4gICAgIHxEQ1MgICAg ICAgICAgICAgIHxFcmljLkx1Y2VAbm9taW51bS5jb20gICAgICAgICAgICB8IAogICAgIHxOb3J0 ZWwgICAgICAgICAgICB8TmV0IElEICAgICAgICAgICB8Z3d3QG5vcnRlbG5ldHdvcmtzLmNvbSAg ICAgICAgICAgfCAKICAgICB8Tm92ZWxsICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfE9uIFRlY2hub2xvZ3kgICAg IHxJUCBUcmFjayAgICAgICAgIHxzdXBwb3J0QG9uLmNvbSAgICAgICAgICAgICAgICAgICB8IAog ICAgIHxQYW5hc29uaWMgICAgICAgICB8S1gtSEdXMjAwICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAKICAgICB8UGF1bCBTbWl0aCAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfCAgIENvbXB1 dGVyIFN2Y3MgIHx2REhDUCAgICAgICAgICAgIHxzdXBwb3J0QHBzY3MuY28udWsgICAgICAgICAg ICAgICB8IAogICAgIHxQR1AgICAgICAgICAgICAgICB8UEdQLTUgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8UGhvZW5peCAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAg fCAgIFRlY2hub2xvZ2llcyAgIHxWaWV3UG9pbnQgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IAogICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAKCgoKICAgICAgCiAgICAgSGli YnMgICAgICAgICAgICAgICAgRXhwaXJlczogT2N0IDIwMDMgKyA2IG1vbnRocyAgICAgICAgICAg W1BhZ2UgMzJdIAoKCgoKCgoKCgoKCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICBSRkMgMjEzMSBJ bXBsZW1lbnRhdGlvbiBJc3N1ZXMgICAgICAgT2N0b2JlciAyMDAzIAogICAgICAKICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gCiAgICAgfFZlbmRvciAgICAgICAgICAgIHxQcm9kdWN0ICAgICAgICAgIHxF LW1haWwgQWRkcmVzcyAgICAgICAgICAgICAgICAgICB8IAogICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAK ICAgICB8UG93ZXJ3YWxseiAgICAgICAgfFByb1NoaWVsZCAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfFByZXNpTkVUIFN5c3RlbXMgIHwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxQcm94aW0g ICAgICAgICAgICB8U2t5bGluZSAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAKICAgICB8UmFwaWRzdHJlYW0gICAgICAgfFJhcGlkc3RyZWFtIDUwMCAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfFNpZW1lbnMgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICAg IHxTbmFwR2VhciAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8c3VwcG9ydEBzbmFwZ2Vhci5j b20gICAgICAgICAgICAgfCAKICAgICB8U29uaWMgV2FsbCAgICAgICAgfFNPSE8gICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfFN1biBNaWNyb3N5 c3RlbXMgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IAogICAgIHxTeW1hbnRlYyAgICAgICAgICB8VlBOLTEwMCAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8VGVuZW8gICAgICAgICAgICAgfE5ldFNj cmVlbiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgfFRo cmVzaG9sZCAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IAogICAgIHwgICBOZXR3b3JrcyAgICAgICB8RWRnZSAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICB8VHJlbGxpcyBOZXR3b3Jr ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg CiAgICAgfCAgIFNlcnZpY2VzICAgICAgIHxETlMgT05FICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IAogICAgIHxXZWlyZCBTb2x1dGlvbnMgICB8REhDUCBUdXJi byAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogICAgICAKICAgICBIaWJi cyAgICAgICAgICAgICAgICBFeHBpcmVzOiBPY3QgMjAwMyArIDYgbW9udGhzICAgICAgICAgICBb UGFnZSAzM10gCgoKCgoKCgoKCg== ------_=_NextPart_001_01C5531D.B98A561E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C5531D.B98A561E-- From dhcwg-bounces@ietf.org Sun May 08 18:32:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUuK9-00039q-6h; Sun, 08 May 2005 18:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUuK5-00036s-WD; Sun, 08 May 2005 18:32:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08886; Sun, 8 May 2005 18:32:27 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUuZ4-0003Rj-E3; Sun, 08 May 2005 18:47:59 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 08 May 2005 18:46:39 -0400 X-IronPort-AV: i="3.92,166,1112587200"; d="scan'208"; a="48297166:sNHT28305056" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j48MWGnI012572; Sun, 8 May 2005 18:32:17 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 8 May 2005 18:32:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 May 2005 18:32:15 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2122D52E@xmb-rtp-20a.amer.cisco.com> Thread-Topic: REMINDER - DHCPv4 options 128-223 soon to be IANA assignable (RFC 3942) Thread-Index: AcT4+CaxGHELjFIeQ46opJGfKOWRvwsKPx9gC78UhCA= From: "Bernie Volz \(volz\)" To: , X-OriginalArrivalTime: 08 May 2005 22:32:16.0622 (UTC) FILETIME=[C9CAC0E0:01C5541D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] REMINDER - DHCPv4 options 128-223 soon to be IANA assignable (RFC 3942) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Just a friendly reminder ... First 6 month notification period ends soon! Hi: A new RFC was recently issued, RFC 3942 (http://www.ietf.org/rfc/rfc3942.txt): "Reclassifying DHCPv4=20 Options". The document is a product of the IETF DHC WG and=20 expands the range of DHCPv4 option numbers that are in the=20 IETF/IANA assignable range. The expanded public range reduces=20 the site-specific options range that was originally defined=20 in RFC 2132.. Old ranges New ranges IETF/IANA assignable: 1-127 1-223 Site-specific: 128-254 224-254 So, why might you care about this? Many vendors have used "site-specific" options in the range=20 128-254 for vendor-specific purposes in shipping products.=20 And, now that IANA can assign options numbers in the range=20 128-223 to future Internet Standard options, we need your=20 assistance to prevent potential conflicts in the use of=20 option codes in the newly expanded range. RFC 3942 has a mechanism whereby IANA will not assign any=20 option codes in the newly expanded range, 128-223, for 6=20 months (this period will end in May 2005). During this 6=20 month period, vendors using options in the 128-223 range=20 should come forward to let IANA and the DHC WG know of their=20 use. IANA can be contacted at mailto:iana@iana.org and the=20 IETF DHC WG can be contacted at mailto:dhcwg@ietf.org. The vendor will also need to write an Internet Draft=20 documenting that usage and advance that draft to an RFC. The=20 Internet Draft can either be written by the vendor or by the=20 vendor providing the material for documenting their usage to=20 Bernie Volz (mailto:volz@cisco.com) for inclusion in a=20 general draft documenting several options. Once the Internet Draft has been published, it will be, at=20 the vendor's discretion, published as an Informational RFC or=20 entered into standards track for publication as an Internet=20 Standard RFC. Therefore, please pass this email on as appropriate and=20 contact Bernie Volz for more information. - Bernie Volz _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 09 11:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAC9-0001R9-AG; Mon, 09 May 2005 11:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAC8-0001R4-AI for dhcwg@megatron.ietf.org; Mon, 09 May 2005 11:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26425 for ; Mon, 9 May 2005 11:29:18 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVARF-00054N-JL for dhcwg@ietf.org; Mon, 09 May 2005 11:44:58 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 17:29:35 +0200 Received: from PXPELLAFOL ([10.193.161.117]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 17:29:16 +0200 From: "Jean-Michel COMBES" To: Date: Mon, 9 May 2005 17:29:16 +0200 Organization: France Telecom R&D Message-ID: <02db01c554ab$dc86a6c0$75a1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 09 May 2005 15:29:16.0741 (UTC) FILETIME=[DC9DFF50:01C554AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] RFC 3315: DHCPv6 server unicast address X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, The RFC 3315 says in:=20 Section 18.1, p39 "If the client has a source address of sufficient scope that can be used = by the server as a return address, and the client has received a Server = Unicast option (section 22.12) from the server, the client SHOULD unicast any Request, Renew, Release and Decline messages to the server." And Annex A, p98 The Server Unicast is only allowed in the REPLY Message So, my question is: If for example, we assume that the DHCPv6 Client has got the DHCPv6 = Server's unicast address from a DNS, why the DHCPv6 Client will not be able to = use the DHCPv6 Server's unicast address until to receive the Unicast Option = (bad case, 4 messages before to be allowed to use it: SOLICIT->ADVERTISE->REQUEST->REPLY)? Thanks for your help. Regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 09 12:02:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAiQ-0007tt-40; Mon, 09 May 2005 12:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAiO-0007tf-Lg for dhcwg@megatron.ietf.org; Mon, 09 May 2005 12:02:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00087 for ; Mon, 9 May 2005 12:02:38 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVAxW-0006S6-GU for dhcwg@ietf.org; Mon, 09 May 2005 12:18:19 -0400 Received: from [192.168.2.3] (dsl093-162-226.tus1.dsl.speakeasy.net [66.93.162.226]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 14999568D6; Mon, 9 May 2005 09:02:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <02db01c554ab$dc86a6c0$75a1c10a@rd.francetelecom.fr> References: <02db01c554ab$dc86a6c0$75a1c10a@rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <332FAC05-F6FA-48AF-A4AE-F0436D6FFB41@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RFC 3315: DHCPv6 server unicast address Date: Mon, 9 May 2005 08:59:00 -0700 To: Jean-Michel COMBES X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 9, 2005, at 8:29 AM, Jean-Michel COMBES wrote: > If for example, we assume that the DHCPv6 Client has got the DHCPv6 > Server's > We don't assume that! The DHCP client gets the DHCPv6 server's IP address by exchanging packets with it. There's no provision in the protocol for a way to look the DHCPv6 server's IP address up in the DNS. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 09 12:18:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAxJ-0003Ax-Qd; Mon, 09 May 2005 12:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAxH-0003As-GW for dhcwg@megatron.ietf.org; Mon, 09 May 2005 12:18:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01783 for ; Mon, 9 May 2005 12:18:01 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVBCP-00077N-FA for dhcwg@ietf.org; Mon, 09 May 2005 12:33:42 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 18:18:15 +0200 Received: from PXPELLAFOL ([10.193.161.117]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 18:17:23 +0200 From: "Jean-Michel COMBES" To: "'Ted Lemon'" Subject: RE : [dhcwg] RFC 3315: DHCPv6 server unicast address Date: Mon, 9 May 2005 18:17:23 +0200 Organization: France Telecom R&D Message-ID: <02f101c554b2$a7e82d10$75a1c10a@rd.francetelecom.fr> 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, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <332FAC05-F6FA-48AF-A4AE-F0436D6FFB41@nominum.com> X-OriginalArrivalTime: 09 May 2005 16:17:54.0821 (UTC) FILETIME=[A7EDAB50:01C554B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Monday, May 09, 2005 5:59 PM > To: COMBES Jean-Michel RD-MAPS > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC 3315: DHCPv6 server unicast address > > > On May 9, 2005, at 8:29 AM, Jean-Michel COMBES wrote: > > If for example, we assume that the DHCPv6 Client has got > the DHCPv6 > > Server's > > > > We don't assume that! The DHCP client gets the DHCPv6 server's IP > address by exchanging packets with it. There's no provision in the > protocol for a way to look the DHCPv6 server's IP address up > in the DNS. > Is it a MUST? If so, where is such a reference? JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 09 13:20:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBvU-0005OR-Vp; Mon, 09 May 2005 13:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBvT-0005OM-HX for dhcwg@megatron.ietf.org; Mon, 09 May 2005 13:20:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08501 for ; Mon, 9 May 2005 13:20:12 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVCAc-00016O-0T for dhcwg@ietf.org; Mon, 09 May 2005 13:35:55 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 9FA82B240B; Mon, 9 May 2005 10:20:00 -0700 (PDT) Date: Mon, 9 May 2005 10:20:00 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size. Message-ID: <20050509172000.GA17500@isc.org> References: <427B506B.1050005@thekelleys.org.uk> <200505071335.26787.budm@weird-solutions.com> Mime-Version: 1.0 In-Reply-To: <200505071335.26787.budm@weird-solutions.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1833381190==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1833381190== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 07, 2005 at 01:35:26PM +0200, Bud Millwood wrote: > And for David: I seem to recall that the ISC DHCP server uses some type > of raw=20 > interface to the network layer; might the ethernet header size be include= d=20 > for that reason? Yes, this was probably done to ensure that the output packet would never exceed 1500 bytes (due to some platform limitation in passing data in sizes larger than that, even though through raw sockets, I am imagining). But this is calculating the maximum size of the "options" space from the client-supplied mms, and consequently the maximum size of the output packet since that's the only variable, rather than directly calculating output packet space. It doesn't matter if the client (or server) is not ethernet, and it doesn't matter if the server is using Berkeley sockets. It's applied in every case. I think this is pretty clearly a bug on our part, but the fact that this is in all released versions of the software of which I am aware (this calculation of "udp overhead" is in RCS version 1.1 of the header, so it appeared in all version-2 releases), I think muddies the 'what does MMS mean' question that's being asked here. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCf5u/cXeLeWu2vmoRAupKAJ0ZhcU+ABVeVlgnt7jVAY4sIJJ4wgCgli8v 0NpEjrOnT8HjqSSUVm3Kjmg= =rycx -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- --===============1833381190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1833381190==-- From dhcwg-bounces@ietf.org Mon May 09 19:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVHwM-0002lu-GS; Mon, 09 May 2005 19:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVHwK-0002im-U5 for dhcwg@megatron.ietf.org; Mon, 09 May 2005 19:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28378 for ; Mon, 9 May 2005 19:45:29 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVIBE-0002Yn-MD for dhcwg@ietf.org; Mon, 09 May 2005 20:01:15 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IG800DYSXYYBE@mailout3.samsung.com> for dhcwg@ietf.org; Tue, 10 May 2005 08:44:58 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IG8000BIXYUQJ@mmp1.samsung.com> for dhcwg@ietf.org; Tue, 10 May 2005 08:44:58 +0900 (KST) Date: Tue, 10 May 2005 08:44:44 +0900 From: "Soohong Daniel Park@SAMSUNG.COM" To: dhcwg@ietf.org Message-id: <00e901c554f1$16062480$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT Subject: [dhcwg] FW: I-D ACTION:draft-daniel-dhc-ipv6in4-opt-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org fyi... >Title : DHCP Option for Configuring IPv6-over-IPv4 Tunnels >Author(s) : S. Park >Filename : draft-daniel-dhc-ipv6in4-opt-06.txt >Pages : 10 >Date : 2005-5-9 > >This document provides a mechanism by which the DHCPv4 servers can >provide information about the IPv6-over-IPv4 tunnel endpoint. The >IPv4/IPv6 dual stack nodes can use this information to set up a >tunnel to the tunnel endpoint to obtain IPv6 connectivity without >requiring manual intervention at any of the tunnel endpoints at >tunnel establishment time. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-06.txt All comments are hightly welcome. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 10 13:03:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVY8S-0002Pt-1F; Tue, 10 May 2005 13:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVY8N-0002J2-9a; Tue, 10 May 2005 13:03:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15879; Tue, 10 May 2005 13:03:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVYNj-0005qb-F3; Tue, 10 May 2005 13:18:55 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DVY8M-0005k0-Kt; Tue, 10 May 2005 13:03:02 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 10 May 2005 13:03:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: 'Detection of Network Attachment (DNA) in IPv4' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'Detection of Network Attachment (DNA) in IPv4 ' 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 2005-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 12 13:31:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWHX2-0007jv-AK; Thu, 12 May 2005 13:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWHWy-0007jq-F3 for dhcwg@megatron.ietf.org; Thu, 12 May 2005 13:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13937 for ; Thu, 12 May 2005 13:31:25 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWHmj-0007Zt-3T for dhcwg@ietf.org; Thu, 12 May 2005 13:47:46 -0400 Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 366193; Thu, 12 May 2005 13:27:01 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 12 May 2005 13:30:40 -0400 To: Ralph Droms , Stig Venaas , tjc@ecs.soton.ac.uk, volz@cisco.com From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-lifetime-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi All The IESG considered draft-ietf-dhc-lifetime-03.txt on our telechat today, and the document was approved for publication as an RFC. The official announcement should be issued soon. Congratulations, Stig, Tim and Bernie! And thanks for your excellent work on this document. Margaret _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 12 15:10:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJ5A-0007kh-4Y; Thu, 12 May 2005 15:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJ58-0007kc-Np for dhcwg@megatron.ietf.org; Thu, 12 May 2005 15:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22860 for ; Thu, 12 May 2005 15:10:49 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWJKu-0001cU-8J for dhcwg@ietf.org; Thu, 12 May 2005 15:27:09 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 May 2005 15:25:42 -0400 X-IronPort-AV: i="3.93,100,1115006400"; d="scan'208"; a="49074075:sNHT28758944" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4CJAFnc019537; Thu, 12 May 2005 15:10:37 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 15:10:36 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 12 May 2005 15:10:35 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2122DB70@xmb-rtp-20a.amer.cisco.com> Thread-Topic: draft-ietf-dhc-lifetime-03.txt Thread-Index: AcVXGGqWZYCj9XgpSESkqyg+UY10UgADdfqw From: "Bernie Volz \(volz\)" To: "Margaret Wasserman" , "Ralph Droms \(rdroms\)" , "Stig Venaas" , X-OriginalArrivalTime: 12 May 2005 19:10:36.0461 (UTC) FILETIME=[472FB5D0:01C55726] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: [dhcwg] RE: draft-ietf-dhc-lifetime-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks! And excellent news!=20 > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 > Sent: Thursday, May 12, 2005 1:31 PM > To: Ralph Droms (rdroms); Stig Venaas; tjc@ecs.soton.ac.uk;=20 > Bernie Volz (volz) > Cc: dhcwg@ietf.org > Subject: draft-ietf-dhc-lifetime-03.txt >=20 >=20 > Hi All >=20 > The IESG considered draft-ietf-dhc-lifetime-03.txt on our telechat=20 > today, and the document was approved for publication as an RFC. The=20 > official announcement should be issued soon. >=20 > Congratulations, Stig, Tim and Bernie! And thanks for your excellent=20 > work on this document. >=20 > Margaret >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 12 15:31:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJOq-0003I1-So; Thu, 12 May 2005 15:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJOp-0003Hv-Du for dhcwg@megatron.ietf.org; Thu, 12 May 2005 15:31:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25721 for ; Thu, 12 May 2005 15:31:09 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWJea-000291-Q1 for dhcwg@ietf.org; Thu, 12 May 2005 15:47:30 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j4CJV1LL020726; Thu, 12 May 2005 21:31:01 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j4CJV4iQ023220; Thu, 12 May 2005 21:31:04 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j4CJV4mt023219; Thu, 12 May 2005 21:31:04 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 May 2005 21:31:04 +0200 From: Stig Venaas To: Margaret Wasserman Message-ID: <20050512193104.GA23182@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, volz@cisco.com, Ralph Droms Subject: [dhcwg] Re: draft-ietf-dhc-lifetime-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks Margaret. Happy to see it going through this quickly and smoothly. Also thanks to all of you in the wg that helped improve the draft and make sure the problems got sorted out early in the process. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 13 05:36:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWWai-0005OS-5P; Fri, 13 May 2005 05:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWWae-0005ON-F5 for dhcwg@megatron.ietf.org; Fri, 13 May 2005 05:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26028 for ; Fri, 13 May 2005 05:36:13 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWWqY-0006on-Cv for dhcwg@ietf.org; Fri, 13 May 2005 05:52:42 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 366748; Fri, 13 May 2005 05:32:02 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 13 May 2005 05:35:57 -0400 To: dhcwg@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: "Wijnen, Bert \(Bert\)" , David Kessens , Brian E Carpenter , Russ Housley Subject: [dhcwg] IESG Review Comments on draft-ietf-dhc-3315id-for-v4-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi All, The IESG reviewed draft-ietf-dhc-3315id-for-v4-04.txt on our telechat yesterday. There were several comments on the document, included below. Issues marked "discuss" are blocking issues that need to be resolved before the document will be approved for publication. Non-blocking comments, marked "comment", should also be considered by the WG and authors, but approval is not blocked pending their resolution. Some of these issues are fairly straight forward to address, but the issue raised by Brian Carpenter and the long set of comments from David Kessens will probably warrant WG discussion. Thanks, Margaret Brian Carpenter: Discuss: [2005-05-12] I expected to find some words stating what happens when a client following this spec meets a server that doesn't, or vice versa. Are these failure scenarios or is there implicit backwards compatibility? This really isn't obvious and should probably be added to the applicability section. Ted Hardie: Comment: [2005-05-10] The document's IANA considerations says: This document deprecates all 'client identifier' type codes other than 255, and thus there is no need for the IANA to track additional possible values for the type field of the 'client identifier' option. I got a bit confused about whether any values registered in this: http://www.iana.org/assignments/bootp-dhcp-parameters are deprecated, or this only deprecates further registration. A clarification may be in order. Sam Hartman: Comment: [2005-05-08] I didn't find this document particularly clear it seemed harder to follow than it should be. I think that's probably because it is a set of diffs to other behavior and has too many references to stand on its own. However I did eventually follow it and I don't think anything I found should block publication at this stage. Russ Housley: Discuss: [2005-05-09] The Introduction says: > > This supersedes the behaviour specified in RFC2131 and RFC2132. > The header and the abstract need to indicate that this document updates RFC 2131 and RFC 2132. Comment: [2005-05-09] Section 2.4 says: > > Like the client identifier format recommended by RFC2131, this > suffers from the problems previously described in (2) and (3). > Section numbers are needed to refer to the previous problems. David Kessens: Discuss: [2005-05-12] I received the following comment from the OPS directorate. I understand from the comment that the issue might have been discussed in the past. I would appreciate if you could reconsider this issue: How is a server expected to handle the case where a single computer first chooses to identify itself with a client identifier, and then later chooses not to supply an identifier at all? This is never clearly explained in any section of RFC2131/2132, so there are three possible interpretations: A) Treat them as two separate, discrete clients. B) Synthesize a client identifier out of the CHADDR field - thus treating clients who identify themselves with their ethernet MAC address as the same client which didn't identify themself, on the same MAC address. C) 'Slide' identities between the two clients. In essence, the lack of a client-identifier is like an "ANY" tag - any lease which was allocated to a client using that CHADDR contents is fair game, and vice versa... any lease which did not have a client identifier but had the same CHADDR is fair game. It might seem that the worst such different interpretations might cause is redundant address allocations - something that gets solved by itself when addresses expire. It's true that this happens, and it's highly undesirable by DHCP server administrators, especially in the case where clients are limited to a certain number of leases (due to contractual levels of service). There exists a "Windows for Embedded Devices" whose product name escapes me right at this moment. Consider then the following reference case: 1) PXE boots and obtains an IP address and configuration via DHCP - it is told to download the Windows boot image. - A server now has a lease allocated to this MAC address in its database, as allocated to a client that did not supply a client identifier. 2) Execution is passed to the Windows boot image - the system already has an IP address, configured by PXE, but Windows wants to query the DHCP server with more, vendor-specific, options added to the 'Options Request List' to get extra configuration state the original PXE client did not know it needed to know. - The Windows boot image sends a DISCOVER message with the address as obtained by PXE in a 'Requested Address' option, and a client identifier whose contents match the CHADDR field. - A server as implimenting interpretation A (above) allocates a new address for the client, since the Windows client did supply a client identifier, and this is interpreted as meaning it is a seperate, distinct client from the former. - The Windows boot image, running within PXE, is unable to alter the network configuration, and instead of REQUESTing the lease it was just offered, continues to resend DISCOVER messages. 3) The system ultimately times out and reboots itself - goto 1). This actually represents an insidious compatibility problem, and I submit it stems from poor definition of the client identifier option in RFC2131/2132. Now, this draft has fine goals - the DHCPv6 Node Identifier that is being duplicated here is the right way to go about client identifiers, and it will serve useful purposes. Not only for the dual-stack purposes of being able to detect what specific clients (as identified by their DUID's) are using both ipv4 and ipv6 addresses, but also for things like Dynamic DNS, and for unusual client configurations (clients having more than one interface - since the server can peek into the client-identifier it can see that a client has multiple interfaces active within a given broadcast domain - you may want to allocate the same address, different addresses, or even different addresses in different subnets within that broadcast domain). Since the old identifiers were 'completely opaque', it's also a reverse compatible approach - servers that treat the client identifier as an opaque field will work acceptably well under all imaginable circumstances when clients supply identifiers in this draft's suggested formats. These are all good things, and we need this draft to reach RFC at some point. But I think we have learned from the past that not defining a "MUST" behaviour for this case - where a client presents itself at different times with a mixture of identities - produces incompatibilities due to differing interpretations. Producing a new format of the client identifier option, and not at least describing this problem much less addressing it, seems to be "not learning from our own mistakes." Understand that the problem is magnified in this draft - In the old RFC2131/2132 world, we could (as I described above) just synthesize a client-identiifer out of the ethernet MAC address and address 99.9% of the problematic cases. But in this draft, we have defined a whole new encoding for the client identifier that has never appeared elsewhere and cannot be synthesized by the DHCP server from any other DHCP packet contents. The only option I believe systems administrators will employ to avoid deployment problems with products conforming to this draft as delivered by products that don't (PXE), is to disable their server's implementation of client identifiers entirely. Which is not at all what we want. So it's a good draft, with good contents, features that we need, but also with what I think is a serious potential problem that I think should be addressed at least as it applies to this draft, if not in general. Bert Wijnen: Discuss: [2005-05-12] I see RFC2119 luanguage (keywords SHOULD and such) without a citation and a normative reference. Comment: [2005-05-12] Mmm... I see citations in the abstract. My understanding is that those are not allowed. Easy to fix, just use perenthesis instead of square brackets. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 13 11:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbeb-0001vW-8w; Fri, 13 May 2005 11:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWbeZ-0001vR-Ea for dhcwg@megatron.ietf.org; Fri, 13 May 2005 11:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22846 for ; Fri, 13 May 2005 11:00:36 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWbuW-0002Zu-AR for dhcwg@ietf.org; Fri, 13 May 2005 11:17:08 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 13 May 2005 11:00:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4DExlnq019194; Fri, 13 May 2005 11:00:27 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:00:23 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: COME ON FOLKS!!!! RE: [dhcwg] dhc WG last call on Date: Fri, 13 May 2005 11:00:22 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> Thread-Topic: COME ON FOLKS!!!! RE: [dhcwg] dhc WG last call on Thread-Index: AcU+zynHPZlbdVPxQpeZ8uCWt4hnjAY/BvtA X-Priority: 1 Priority: Urgent Importance: high From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , X-OriginalArrivalTime: 13 May 2005 15:00:23.0082 (UTC) FILETIME=[7CEDA0A0:01C557CC] X-Spam-Score: 2.7 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: Stig Venaas X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I don't believe there were ANY responses to this WG last call. Either positive or negative. Now, we can all complain about the slow progress within the IETF, but WE ARE THE CAUSE OF THOSE PROBLEMS! Not the IESG. The FQDN related work has been stalled for YEARS! Several different people have worked on it and it has never been brought to closure. Well, I thought we finally had a good chance to bring this work to a close, but it just won't happen if YOU ALL don't want it to happen. Apparently no one cares about this issue?? And this document, as I understand it, is the last piece of work holding up the FQDN drafts (though of course there may be issues raised within the IETF last call and/or IESG review). As the WG Last Call period has officially ended, I don't know if the chairs will accept comments, but it certainly can't hurt for people to respond one way or another. Personally, I'm not going to put a lot more effort into this work if the WG won't support it. So, it will soon fall to yet another person or group to complete this work (if it ever will be). Sorry for the rant. - Bernie =20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Monday, April 11, 2005 3:08 PM > To: dhcwg@ietf.org > Cc: Stig Venaas > Subject: [dhcwg] dhc WG last call on=20 > >=20 >=20 > This message announces a WG last call on "Resolution of DNS > Name Conflicts among DHCP Clients" > . The last call will > conclude at 1700 EST (USA) on 2005-04-25. >=20 > Please respond to this WG last call. If you support > acceptance of the document without change, respond with a > simple acknowledgment, so that support for the document can > be assessed. Lack of discussion does not represent positive > support. If there is no expression of support for > acceptance during the WG last call, the document will not be > advanced to the IESG. >=20 > There are options in DHCP that can be used for transmitting > information about updating DNS. However, these do not > explicitly control updating the name to address and address > to name mappings maintained in the DNS, as performed by > hosts acting as DHCP clients and servers. > draft-ietf-dhc-ddns-resolution-08.txt describes techniques > for the resolution of DNS name conflicts among DHCP clients > and servers. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns- > resolution-08.txt >=20 > - Ralph Droms=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 13 14:29:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeuf-0004if-De; Fri, 13 May 2005 14:29:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeud-0004iX-K1 for dhcwg@megatron.ietf.org; Fri, 13 May 2005 14:29:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12010 for ; Fri, 13 May 2005 14:29:25 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfAa-0002lJ-Ul for dhcwg@ietf.org; Fri, 13 May 2005 14:45:58 -0400 Received: from [81.200.65.30] (dhcp-30.wl.nominum.com [81.200.65.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id BEEF3568BE; Fri, 13 May 2005 11:29:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 1 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AC14166-2044-4974-9399-A6457982B8DA@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: COME ON FOLKS!!!! RE: [dhcwg] dhc WG last call on Date: Fri, 13 May 2005 11:25:42 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 1.8 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Stig Venaas , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I was under the apparently mistaken impression that I'd responded to the last call. Assuming I have not, please accept my apologies. I do indeed want this draft to advance to RFC, ASAP. It's been a long time coming. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 13 14:37:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf2B-0006Dt-CW; Fri, 13 May 2005 14:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf2A-0006Do-CK for dhcwg@megatron.ietf.org; Fri, 13 May 2005 14:37:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12654 for ; Fri, 13 May 2005 14:37:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfI8-00035L-4d for dhcwg@ietf.org; Fri, 13 May 2005 14:53:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 May 2005 11:37:04 -0700 X-IronPort-AV: i="3.93,107,1115017200"; d="scan'208"; a="264952393:sNHT31237608" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4DIahQ0024853 for ; Fri, 13 May 2005 11:37:01 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:37:00 -0700 Received: from [161.44.65.205] ([161.44.65.205]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 11:36:39 -0700 Message-ID: <4284F36B.605@cisco.com> Date: Fri, 13 May 2005 14:35:23 -0400 From: Mark Stapp User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernie Volz (volz)" Subject: Re: COME ON FOLKS!!!! RE: [dhcwg] dhc WG last call on References: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2005 18:36:39.0479 (UTC) FILETIME=[B376AC70:01C557EA] X-Spam-Score: 1.3 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org yes, I want this draft to advance to the iesg (and, just maybe, beyond) thank you for your energy and determination, Bernie! -- Mark Bernie Volz (volz) wrote: >I don't believe there were ANY responses to this WG last call. Either >positive or negative. > >Now, we can all complain about the slow progress within the IETF, but WE >ARE THE CAUSE OF THOSE PROBLEMS! Not the IESG. > >The FQDN related work has been stalled for YEARS! Several different >people have worked on it and it has never been brought to closure. > >Well, I thought we finally had a good chance to bring this work to a >close, but it just won't happen if YOU ALL don't want it to happen. >Apparently no one cares about this issue?? > >And this document, as I understand it, is the last piece of work holding >up the FQDN drafts (though of course there may be issues raised within >the IETF last call and/or IESG review). > >As the WG Last Call period has officially ended, I don't know if the >chairs will accept comments, but it certainly can't hurt for people to >respond one way or another. > >Personally, I'm not going to put a lot more effort into this work if the >WG won't support it. So, it will soon fall to yet another person or >group to complete this work (if it ever will be). > >Sorry for the rant. > >- Bernie > > > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >>On Behalf Of Ralph Droms >>Sent: Monday, April 11, 2005 3:08 PM >>To: dhcwg@ietf.org >>Cc: Stig Venaas >>Subject: [dhcwg] dhc WG last call on >> >> >> >>This message announces a WG last call on "Resolution of DNS >>Name Conflicts among DHCP Clients" >>. The last call will >>conclude at 1700 EST (USA) on 2005-04-25. >> >>Please respond to this WG last call. If you support >>acceptance of the document without change, respond with a >>simple acknowledgment, so that support for the document can >>be assessed. Lack of discussion does not represent positive >>support. If there is no expression of support for >>acceptance during the WG last call, the document will not be >>advanced to the IESG. >> >>There are options in DHCP that can be used for transmitting >>information about updating DNS. However, these do not >>explicitly control updating the name to address and address >>to name mappings maintained in the DNS, as performed by >>hosts acting as DHCP clients and servers. >>draft-ietf-dhc-ddns-resolution-08.txt describes techniques >>for the resolution of DNS name conflicts among DHCP clients >>and servers. This draft is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns- >>resolution-08.txt >> >>- Ralph Droms >> >> >>_______________________________________________ >>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-bounces@ietf.org Fri May 13 15:00:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWfOL-0000vN-VC; Fri, 13 May 2005 15:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWfOL-0000us-5D for dhcwg@megatron.ietf.org; Fri, 13 May 2005 15:00:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14232 for ; Fri, 13 May 2005 15:00:06 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfeI-0003wU-Tt for dhcwg@ietf.org; Fri, 13 May 2005 15:16:40 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id EB189B240B; Fri, 13 May 2005 11:59:54 -0700 (PDT) Date: Fri, 13 May 2005 11:59:54 -0700 From: "David W. Hankins" To: "Bernie Volz (volz)" Subject: Re: COME ON FOLKS!!!! RE: [dhcwg] dhc WG last call on Message-ID: <20050513185954.GD3365@isc.org> References: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB2122DC47@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 1.3 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dhcwg@ietf.org, Stig Venaas , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892033635==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0892033635== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MnLPg7ZWsaic7Fhd" Content-Disposition: inline --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 13, 2005 at 11:00:22AM -0400, Bernie Volz (volz) wrote: > Sorry for the rant. My apologies, Bernie. I had intended to give comments after I updated our sources to reflect some of the changes...so I could reread our sources and comment on any surprises that might crop up. I overestimated how much time I would have to accomplish this. The draft is ready to go to the IESG. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --MnLPg7ZWsaic7Fhd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFChPkqcXeLeWu2vmoRAmy8AJ4rHYmfARFawO4cOFWD/2iYH5tpMwCeONhv hDgJvH8EV5kIl2J0SeckaIc= =Zwpg -----END PGP SIGNATURE----- --MnLPg7ZWsaic7Fhd-- --===============0892033635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0892033635==-- From dhcwg-bounces@ietf.org Sat May 14 04:34:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWs6l-0005bF-W9; Sat, 14 May 2005 04:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWs6k-0005b3-31; Sat, 14 May 2005 04:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14145; Sat, 14 May 2005 04:34:47 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWsMp-0004tJ-SS; Sat, 14 May 2005 04:51:28 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 209B715210; Sat, 14 May 2005 17:36:43 +0900 (JST) Date: Sat, 14 May 2005 17:35:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: <1114538312.6886.17.camel@localhost.localdomain> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dhcwg@ietf.org, IPv6 WG , Ralph Droms Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST), >>>>> Pekka Savola said: >>>> I can think of several possible resolutions: >>>> >>>> 1. just say that it's host/network administrator's responsibility to >>>> provide consistent parameters/configurations. In this sense, the >>>> combination of a) and b) above is just a configuration error. >>>> This would be the most lightweight resolution for the authors:-), >>>> but I personally think it's irresponsible. >>> >>> I agree as well. This is not good enough. >> >> I think it's perfectly reasonable to assume that a configuration >> mismatch is admin error and leave it at that - in this case, the RAs are >> configured incorrectly, promising that a non-existent address assignment >> service is available. > That would be consistent if the presence of M-flag would only trigger > DHCPv6 for address assignment, but DHCPv6 would not be used to > configure anything else at all unless O-flag was also appropriately > set. > Then the DHCPv6 and DHCPv6-lite would function in a similar fashion > from the network administrator's perspective. > So, IMHO, either we must require O flag always for Information > Configuration (whether DHCPv6 full or lite) or support the > administrators who can't make out the subtle difference about the > appropriate configuration of the flags. For that, guidance for full > DHCPv6 implementers to also try emulating DHCPv6 lite would probably > be sufficient. I've been thinking about this issue for a while, and I now feel it may require a more profound discussion than I originally thought... Here are some background points: - In original RFC2462, if ManagedFlag (host's variable corresponding to the M flag of RA) is TRUE, it implicitly means OtherConfigFlag is also TRUE (Section 5.2). It would mean if we receive an RA with M=on (whether O=on or off), the receiving host would start the "stateful" protocol (which we now know is DHCPv6) for address configuration *and* the "stateful" protocol for configuration information excluding addresses (Section 5.5.3). - In the past discussion about the M/O flag document, we clarified that the notion of "M" and "O" is quite independent. That is, "M" means the "Host Configuration Behavior", which, more specifically, means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" means the "Information Configuration Behavior", which means DHCPv6 an Information-request/Reply exchange. Unlike RFC2462, there is no implicit dependency between "O-Flag" (renamed from OtherConfigFlag to avoid confusion) and the M flag in this document. So, for example, the host does not invoke the "Information Configuration Behavior" just because the M flag in an RA is ON. I guess the slightly different sense led us to the current confusion (or problem). If we respect both the original sense of RFC2462 and our consensus about the semantics separation of the M/O flags, I believe the right solution is the following: - allow (or even require) running the Host Configuration Behavior and the Information Configuration Behavior concurrently. (note: this is a significant change from the current M/O document) - note that the same type of configuration information (e.g., recursive DNS server addresses) can be obtained with those two behaviors, and that how to deal with possible inconsistency is beyond the scope of the M/O document. - also note that the network administrator should by default provide the Information Configuration Behavior when they provide the Host Configuration Behavior, in which case both the M and O flags should be set to ON in router advertisements. With the last notice, I'm fine with the position of saying "it's administrator's responsibility to ensure service consistency". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 09:56:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXg5V-0005jx-IW; Mon, 16 May 2005 09:56:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXg5P-0005ec-Sr; Mon, 16 May 2005 09:56:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14046; Mon, 16 May 2005 09:56:46 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXgLw-0004bj-Pz; Mon, 16 May 2005 10:13:54 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 May 2005 10:12:19 -0400 X-IronPort-AV: i="3.93,111,1115006400"; d="scan'208"; a="49575145:sNHT32825652" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GDu7nW025063; Mon, 16 May 2005 09:56:34 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 09:56:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Mon, 16 May 2005 09:56:26 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVYYFPIrJ1r0kF3RvCSQN0HVF4HVwBvUAwA From: "Bernie Volz \(volz\)" To: "JINMEI Tatuya / ????" , "Pekka Savola" X-OriginalArrivalTime: 16 May 2005 13:56:27.0610 (UTC) FILETIME=[0E0C4BA0:01C55A1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I haven't followed this thread carefully, but are you trying to suggest that if the M flag is set but O is not, that a client would IGNORE the other configuration parameters received from a DHCP server in a Solicit/Advertise/Request/Reply sequence? That seems very bad to me. And a waste of resources to have to do two sets of transactions (Solicit/Advertise/Request/Reply for addresses and Information-Request/Reply for other configuration). I really don't understand why this issue has been so difficult to resolve. In IPv4, DHCP is often the default unless you explicitly configure an interface or turn DHCP off. We don't have ANY network wide configuration for this. And it works very well indeed. In IPv6, the M and O flag should serve as hints. Period. A host is perfectly free to do what it wants (or what it has been configured to do). The M flag, if set, means a host SHOULD do full-RFC 3315. This means they should attempt to Solicit, but can also fall back to Information-Request if needed. This means both addresses and other configuration are configured, if available. The O flag, if set, means a host SHOULD do RFC 3376 (partial RFC 3315). If both flags are set, hosts that can do full RFC 3315 do it (and ignore the O flag). Those that can only do RFC 3376, do that. If no flag it set, hosts may still do RFC 3315 and/or 3376 if so configured (whether by default or otherwise). There should be no prohibition against doing that. The document need not say this - it is implied because we MUST NOT use MUST or MUST NOT. Just SHOULD or SHOULD NOT when taking about the bits. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of jinmei@isl.rdc.toshiba.co.jp > Sent: Saturday, May 14, 2005 4:36 AM > To: Pekka Savola > Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms) > Subject: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > >>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST),=20 > >>>>> Pekka Savola said: >=20 > >>>> I can think of several possible resolutions: > >>>>=20 > >>>> 1. just say that it's host/network administrator's=20 > responsibility to > >>>> provide consistent parameters/configurations. In this sense, the > >>>> combination of a) and b) above is just a configuration error. > >>>> This would be the most lightweight resolution for the authors:-), > >>>> but I personally think it's irresponsible. > >>>=20 > >>> I agree as well. This is not good enough. > >>=20 > >> I think it's perfectly reasonable to assume that a configuration > >> mismatch is admin error and leave it at that - in this=20 > case, the RAs are > >> configured incorrectly, promising that a non-existent=20 > address assignment > >> service is available. >=20 > > That would be consistent if the presence of M-flag would=20 > only trigger=20 > > DHCPv6 for address assignment, but DHCPv6 would not be used to=20 > > configure anything else at all unless O-flag was also appropriately=20 > > set. >=20 > > Then the DHCPv6 and DHCPv6-lite would function in a similar fashion=20 > > from the network administrator's perspective. >=20 > > So, IMHO, either we must require O flag always for Information=20 > > Configuration (whether DHCPv6 full or lite) or support the=20 > > administrators who can't make out the subtle difference about the=20 > > appropriate configuration of the flags. For that, guidance=20 > for full=20 > > DHCPv6 implementers to also try emulating DHCPv6 lite would=20 > probably=20 > > be sufficient. >=20 > I've been thinking about this issue for a while, and I now feel it may > require a more profound discussion than I originally thought... >=20 > Here are some background points: >=20 > - In original RFC2462, if ManagedFlag (host's variable corresponding > to the M flag of RA) is TRUE, it implicitly means OtherConfigFlag is > also TRUE (Section 5.2). It would mean if we receive an RA with > M=3Don (whether O=3Don or off), the receiving host would start the > "stateful" protocol (which we now know is DHCPv6) for address > configuration *and* the "stateful" protocol for configuration > information excluding addresses (Section 5.5.3). >=20 > - In the past discussion about the M/O flag document, we clarified > that the notion of "M" and "O" is quite independent. That is, "M" > means the "Host Configuration Behavior", which, more specifically, > means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" > means the "Information Configuration Behavior", which means DHCPv6 > an Information-request/Reply exchange. Unlike RFC2462, there is no > implicit dependency between "O-Flag" (renamed from OtherConfigFlag > to avoid confusion) and the M flag in this document. So, for > example, the host does not invoke the "Information Configuration > Behavior" just because the M flag in an RA is ON. >=20 > I guess the slightly different sense led us to the current confusion > (or problem). >=20 > If we respect both the original sense of RFC2462 and our consensus > about the semantics separation of the M/O flags, I believe the right > solution is the following: >=20 > - allow (or even require) running the Host Configuration Behavior > and the Information Configuration Behavior concurrently. (note: > this is a significant change from the current M/O document) > - note that the same type of configuration information (e.g., > recursive DNS server addresses) can be obtained with those two > behaviors, and that how to deal with possible inconsistency is > beyond the scope of the M/O document. > - also note that the network administrator should by default provide > the Information Configuration Behavior when they provide the Host > Configuration Behavior, in which case both the M and O flags > should be set to ON in router advertisements. >=20 > With the last notice, I'm fine with the position of saying "it's > administrator's responsibility to ensure service consistency". >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 13:11:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXj8I-0007bW-Ty; Mon, 16 May 2005 13:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXj8F-0007av-G9; Mon, 16 May 2005 13:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12211; Mon, 16 May 2005 13:11:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjOp-000426-CS; Mon, 16 May 2005 13:29:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 May 2005 13:11:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4GHB3ea018839; Mon, 16 May 2005 13:11:43 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 13:11:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Mon, 16 May 2005 13:11:41 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVYYFPIrJ1r0kF3RvCSQN0HVF4HVwBvUAwAAAahuqA= From: "Bernie Volz \(volz\)" To: "JINMEI Tatuya / ????" , "Pekka Savola" X-OriginalArrivalTime: 16 May 2005 17:11:42.0100 (UTC) FILETIME=[546D9D40:01C55A3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org BTW, if you want to look at this from the router administrator's perspective: Configure the router to send the M flag set in routing advertisements for a Link IF: 1. A stateful DHCP server is deployed for that link (either on it or reachable via a relay agent) AND 2. At least ONE or more prefixes the router is advertising for that link are NOT configured for stateless auto-configuration. Configure the router to send the O flag set in routing advertisements for a link IF: 1. A stateful or stateless DHCP server is deployed for that link (either on it or reachable via a relay agent) AND 2. At least ONE or more prefixes the router is advertising for that link ALLOW stateless auto-configuration OR there are resources available to the clients on that link that are reachable via link-local addresses (such as an SNTP server). The latter may change over time depending on what other configuration settings are available, but with the present set of IETF options there is little value in providing any of the other configuration settings if the client can only use link-local addresses. So, the 4 possible combinations of the M&O bit may appear and be used. For example, the M may be set but the O clear if no stateless auto configuration for any address is possible (and there are no link-local resources available to the client that can be configured via DHCP). The M may be clear if there are no stateful addresses for the link. In this case, the O would be set if there are more than link-local addresses advertised. Both the M & O would be set if one or more stateful addresses is present, but stateless addresses are also available. Clients that don't support stateful would still need the other configuration parameters and could likely communicate with those resources since they have non-link-local addresses. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Bernie Volz (volz) > Sent: Monday, May 16, 2005 9:56 AM > To: JINMEI Tatuya / ????; Pekka Savola > Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > I haven't followed this thread carefully, but are you trying > to suggest > that if the M flag is set but O is not, that a client would IGNORE the > other configuration parameters received from a DHCP server in a > Solicit/Advertise/Request/Reply sequence? That seems very bad > to me. And > a waste of resources to have to do two sets of transactions > (Solicit/Advertise/Request/Reply for addresses and > Information-Request/Reply for other configuration). > > I really don't understand why this issue has been so difficult to > resolve. > > In IPv4, DHCP is often the default unless you explicitly configure an > interface or turn DHCP off. We don't have ANY network wide > configuration > for this. And it works very well indeed. > > In IPv6, the M and O flag should serve as hints. Period. A host is > perfectly free to do what it wants (or what it has been configured to > do). > > The M flag, if set, means a host SHOULD do full-RFC 3315. This means > they should attempt to Solicit, but can also fall back to > Information-Request if needed. This means both addresses and other > configuration are configured, if available. > > The O flag, if set, means a host SHOULD do RFC 3376 (partial > RFC 3315). > > If both flags are set, hosts that can do full RFC 3315 do it > (and ignore > the O flag). Those that can only do RFC 3376, do that. > > If no flag it set, hosts may still do RFC 3315 and/or 3376 if so > configured (whether by default or otherwise). There should be no > prohibition against doing that. The document need not say this - it is > implied because we MUST NOT use MUST or MUST NOT. Just SHOULD > or SHOULD > NOT when taking about the bits. > > - Bernie > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of jinmei@isl.rdc.toshiba.co.jp > > Sent: Saturday, May 14, 2005 4:36 AM > > To: Pekka Savola > > Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms) > > Subject: [dhcwg] Re: IPv6 WG Last > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > > > >>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST), > > >>>>> Pekka Savola said: > > > > >>>> I can think of several possible resolutions: > > >>>> > > >>>> 1. just say that it's host/network administrator's > > responsibility to > > >>>> provide consistent parameters/configurations. In this > sense, the > > >>>> combination of a) and b) above is just a configuration error. > > >>>> This would be the most lightweight resolution for the > authors:-), > > >>>> but I personally think it's irresponsible. > > >>> > > >>> I agree as well. This is not good enough. > > >> > > >> I think it's perfectly reasonable to assume that a configuration > > >> mismatch is admin error and leave it at that - in this > > case, the RAs are > > >> configured incorrectly, promising that a non-existent > > address assignment > > >> service is available. > > > > > That would be consistent if the presence of M-flag would > > only trigger > > > DHCPv6 for address assignment, but DHCPv6 would not be used to > > > configure anything else at all unless O-flag was also > appropriately > > > set. > > > > > Then the DHCPv6 and DHCPv6-lite would function in a > similar fashion > > > from the network administrator's perspective. > > > > > So, IMHO, either we must require O flag always for Information > > > Configuration (whether DHCPv6 full or lite) or support the > > > administrators who can't make out the subtle difference about the > > > appropriate configuration of the flags. For that, guidance > > for full > > > DHCPv6 implementers to also try emulating DHCPv6 lite would > > probably > > > be sufficient. > > > > I've been thinking about this issue for a while, and I now > feel it may > > require a more profound discussion than I originally thought... > > > > Here are some background points: > > > > - In original RFC2462, if ManagedFlag (host's variable corresponding > > to the M flag of RA) is TRUE, it implicitly means > OtherConfigFlag is > > also TRUE (Section 5.2). It would mean if we receive an RA with > > M=3Don (whether O=3Don or off), the receiving host would start the > > "stateful" protocol (which we now know is DHCPv6) for address > > configuration *and* the "stateful" protocol for configuration > > information excluding addresses (Section 5.5.3). > > > > - In the past discussion about the M/O flag document, we clarified > > that the notion of "M" and "O" is quite independent. That is, "M" > > means the "Host Configuration Behavior", which, more specifically, > > means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" > > means the "Information Configuration Behavior", which means DHCPv6 > > an Information-request/Reply exchange. Unlike RFC2462, > there is no > > implicit dependency between "O-Flag" (renamed from OtherConfigFlag > > to avoid confusion) and the M flag in this document. So, for > > example, the host does not invoke the "Information Configuration > > Behavior" just because the M flag in an RA is ON. > > > > I guess the slightly different sense led us to the current confusion > > (or problem). > > > > If we respect both the original sense of RFC2462 and our consensus > > about the semantics separation of the M/O flags, I believe the right > > solution is the following: > > > > - allow (or even require) running the Host Configuration Behavior > > and the Information Configuration Behavior concurrently. (note: > > this is a significant change from the current M/O document) > > - note that the same type of configuration information (e.g., > > recursive DNS server addresses) can be obtained with those two > > behaviors, and that how to deal with possible inconsistency is > > beyond the scope of the M/O document. > > - also note that the network administrator should by > default provide > > the Information Configuration Behavior when they > provide the Host > > Configuration Behavior, in which case both the M and O flags > > should be set to ON in router advertisements. > > > > With the last notice, I'm fine with the position of saying "it's > > administrator's responsibility to ensure service consistency". > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > _______________________________________________ > > 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 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 13:21:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjHU-0001Gv-Dw; Mon, 16 May 2005 13:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjHR-0001GL-De; Mon, 16 May 2005 13:21:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13336; Mon, 16 May 2005 13:21:20 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjXw-0004VT-DW; Mon, 16 May 2005 13:38:31 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j4GHLALL013727; Mon, 16 May 2005 19:21:10 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j4GHLKLe022681; Mon, 16 May 2005 19:21:20 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j4GHLKx7022680; Mon, 16 May 2005 19:21:20 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 16 May 2005 19:21:20 +0200 From: Stig Venaas To: "Bernie Volz (volz)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Message-ID: <20050516172120.GA22530@storhaugen.uninett.no> References: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , Pekka Savola X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Another reason they need to be only hints to the clients, is that there might be many different types of clients on the same link. I think there are many cases where you don't want to force all the clients to do the same. One thing is what information a client wants to obtain, another is what it supports. Does the client do DHCP at all, does it just do state- less, or does it do the full 3315. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 13:50:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjj9-0008DG-Il; Mon, 16 May 2005 13:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjj6-0008Bv-W1; Mon, 16 May 2005 13:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16358; Mon, 16 May 2005 13:49:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjze-0005ik-Hu; Mon, 16 May 2005 14:07:09 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 May 2005 13:49:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GHnCnk007859; Mon, 16 May 2005 13:49:46 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 13:49:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Mon, 16 May 2005 13:49:42 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B349C@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVaO7qacjUC63UyRmyhTG/+d1ICtAAA8+pQ From: "Bernie Volz \(volz\)" To: "Stig Venaas" X-OriginalArrivalTime: 16 May 2005 17:49:43.0274 (UTC) FILETIME=[A41D24A0:01C55A3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , Pekka Savola X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Exactly!=20 > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Monday, May 16, 2005 1:21 PM > To: Bernie Volz (volz) > Cc: JINMEI Tatuya / ????; Pekka Savola; dhcwg@ietf.org; IPv6=20 > WG; Ralph Droms (rdroms) > Subject: Re: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Another reason they need to be only hints to the clients, is=20 > that there > might be many different types of clients on the same link. I=20 > think there > are many cases where you don't want to force all the clients to do the > same. One thing is what information a client wants to obtain,=20 > another is > what it supports. Does the client do DHCP at all, does it=20 > just do state- > less, or does it do the full 3315. >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 17:10:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmqp-0007nm-J5; Mon, 16 May 2005 17:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmql-0007n8-DA; Mon, 16 May 2005 17:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20865; Mon, 16 May 2005 17:10:04 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXn7M-0002GS-B7; Mon, 16 May 2005 17:27:17 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4GL8Wf31311; Tue, 17 May 2005 00:08:32 +0300 Date: Tue, 17 May 2005 00:08:32 +0300 (EEST) From: Pekka Savola To: "Bernie Volz (volz)" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> Message-ID: References: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, 16 May 2005, Bernie Volz (volz) wrote: > BTW, if you want to look at this from the router administrator's > perspective: > > Configure the router to send the M flag set in routing advertisements > for a Link IF: > 1. A stateful DHCP server is deployed for that link (either on it or > reachable via a relay agent) AND IMHO, you're making a significant leap of faith in assuming that whoever configures the router's M-flag advertisements has sufficient clue to grasp the different semantics that arise with: - M-flag and/or O-flag - stateless and stateful clients - stateless and stateful servers - stateless and stateful relay agents Hence, if we want to build a robust system, we need to design it with care. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 17:21:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXn1n-0002LP-19; Mon, 16 May 2005 17:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXn1k-0002Kq-K7; Mon, 16 May 2005 17:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21832; Mon, 16 May 2005 17:21:26 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXnIL-0002kH-SX; Mon, 16 May 2005 17:38:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 May 2005 17:35:50 -0400 X-IronPort-AV: i="3.93,112,1115006400"; d="scan'208"; a="49662067:sNHT2837838494" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GLJCni012488; Mon, 16 May 2005 17:20:00 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 17:19:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Mon, 16 May 2005 17:19:59 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3553@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVaW85E7las8HC2Qs2YF0DjHsb1NgAAPbwg From: "Bernie Volz \(volz\)" To: "Pekka Savola" X-OriginalArrivalTime: 16 May 2005 21:19:59.0948 (UTC) FILETIME=[043CD0C0:01C55A5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hey, if they don't know what they're doing then set the bits and be done with it. If there's no DHCP server, the clients will try to get configuration information and fail and continuously try in the background. That's the safest fallback and the recommended default, IMHO. If they do set them wrong, it won't take long for users to complain. Just as they do now if the DHCP server or routing infrastructure is down. Trying to design for stupidity only produces the same. - Bernie=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Monday, May 16, 2005 5:09 PM > To: Bernie Volz (volz) > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph=20 > Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > BTW, if you want to look at this from the router administrator's > > perspective: > > > > Configure the router to send the M flag set in routing=20 > advertisements > > for a Link IF: > > 1. A stateful DHCP server is deployed for that link (either on it or > > reachable via a relay agent) AND >=20 > IMHO, you're making a significant leap of faith in assuming that=20 > whoever configures the router's M-flag advertisements has sufficient=20 > clue to grasp the different semantics that arise with: >=20 > - M-flag and/or O-flag > - stateless and stateful clients > - stateless and stateful servers > - stateless and stateful relay agents >=20 > Hence, if we want to build a robust system, we need to design it with=20 > care. >=20 >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 16 17:44:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnO9-0000Fv-Df; Mon, 16 May 2005 17:44:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnO2-0008Sf-TX; Mon, 16 May 2005 17:44:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25211; Mon, 16 May 2005 17:44:28 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXnef-0004CS-Hv; Mon, 16 May 2005 18:01:41 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DXnO1-00076K-Q6; Mon, 16 May 2005 17:44:29 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 16 May 2005 17:44:29 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: dhc mailing list , dhc chair , Internet Architecture Board , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Information Refresh Time Option for DHCPv6' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'Information Refresh Time Option for DHCPv6 ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. - Technical Summary A host that uses stateless address autoconfiguration (RFC 2462) will still require the configuration of other configuration information. DHCPv6 (RFC 3315, RFC 3736) is one way in which a host might obtain other configuration information. The mechanism described in RFC 3736, "stateless DHCPv6", provides configuration information but does not give the host any indication of when the DHCPv6 server should be contacted to refresh that configuration information. This document describes a DHCPv6 option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. The option specified in this document meets the requirements of draft-ietf-dhc-stateless-dhcpv6-renumbering, which has been accepted for publication as an Informational RFC. - Working Group Summary The dhc WG developed, discussed and published draft-ietf-dhc-stateless-dhcpv6-renumbering, which defines the requirements for managing the updating of configuration parameters obtained through stateless DHCPv6. The specification in this document has been given thorough review by the dhc WG. During the review, several issues about details of the configuration update process were resolved through discussion in the WG mailing list. - Protocol Quality The protocol specified in this document is a simple extension to the DHCPv6 protocol, which would have been appropriate to include in RFC 3315. The option has been implemented in KAME DHCP server and in Lucent DHCP client. The two implementations have been tested for interoperability. From Joe Quanaim prior to previous IETF: Since the lifetime draft will be discussed next week at the ietf, I thought I would let you know that I have implemented the functionality in a dhcpv6 client and successfully tested it against the kame server implementation. I figure it might help to be able to cite implementations. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 17 15:41:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wp-0006k8-Gc; Tue, 17 May 2005 15:41:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wm-0006g9-NL; Tue, 17 May 2005 15:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01281; Tue, 17 May 2005 15:41:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8Da-0002be-SH; Tue, 17 May 2005 15:59:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 15:41:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4HJexni015571; Tue, 17 May 2005 15:41:27 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 15:41:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Tue, 17 May 2005 15:41:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B370E@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVahGdhDLV9JhwsRneDDXLPFEI82gAk6wCg From: "Bernie Volz \(volz\)" To: "timothy enos" , "Pekka Savola" X-OriginalArrivalTime: 17 May 2005 19:41:26.0296 (UTC) FILETIME=[69D6E180:01C55B18] X-Spam-Score: 1.1 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Tim: I'm not sure what you mean by your question ... SLAC (stateless auto-configuration) is independent of stateful. There may be some prefixes on a link that are stateful (0 or more) and others that are stateless (0 or more - excluding the link-local which is always stateless). So, SLAC is independent of stateful (DHCPv6). - Bernie > -----Original Message----- > From: timothy enos [mailto:timbeck04@verizon.net]=20 > Sent: Monday, May 16, 2005 10:00 PM > To: Bernie Volz (volz); 'Pekka Savola' > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI=20 > Tatuya / ????' > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Bernie, > =09 > Your points are well taken, and I agree. Making these flags 'hints' > makes sense. Also, it seems that if a client does not know what to do > (forgive the anthropomorphism) in response to having received=20 > an RA with > the M (and O) bit(s) set (because it is not a DHCPv6 client), it would > just ignore it/them.=20 >=20 > Also wondering if there are any RFC 3315-capable clients that, after > failing to get config info from a DHCPv6 server 'x' times,=20 > would revert > to SLAC? >=20 > Tim Enos > 1Sam16:7 >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of > Bernie Volz (volz) > Sent: Monday, May 16, 2005 5:20 PM > To: Pekka Savola > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI=20 > Tatuya / ???? > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Hey, if they don't know what they're doing then set the bits=20 > and be done > with it. If there's no DHCP server, the clients will try to get > configuration information and fail and continuously try in the > background. That's the safest fallback and the recommended default, > IMHO. >=20 > If they do set them wrong, it won't take long for users to complain. > Just as they do now if the DHCP server or routing infrastructure is > down. >=20 > Trying to design for stupidity only produces the same. >=20 > - Bernie=20 >=20 > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > > Sent: Monday, May 16, 2005 5:09 PM > > To: Bernie Volz (volz) > > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph=20 > > Droms (rdroms) > > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > >=20 > > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > > BTW, if you want to look at this from the router administrator's > > > perspective: > > > > > > Configure the router to send the M flag set in routing=20 > > advertisements > > > for a Link IF: > > > 1. A stateful DHCP server is deployed for that link=20 > (either on it or > > > reachable via a relay agent) AND > >=20 > > IMHO, you're making a significant leap of faith in assuming that=20 > > whoever configures the router's M-flag advertisements has=20 > sufficient=20 > > clue to grasp the different semantics that arise with: > >=20 > > - M-flag and/or O-flag > > - stateless and stateful clients > > - stateless and stateful servers > > - stateless and stateful relay agents > >=20 > > Hence, if we want to build a robust system, we need to=20 > design it with=20 > > care. > >=20 > >=20 > >=20 > > --=20 > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 17 15:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7zj-00075d-4P; Tue, 17 May 2005 15:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7zf-00074U-W3; Tue, 17 May 2005 15:44:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01510; Tue, 17 May 2005 15:44:41 -0400 (EDT) Message-Id: <200505171944.PAA01510@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 17 May 2005 15:44:41 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-bcmc-options-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@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 : DHCP Options for Broadcast and Multicast Control Servers Author(s) : K. Chowdhury, et al. Filename : draft-ietf-dhc-bcmc-options-01.txt Pages : 14 Date : 2005-5-17 This document defines new options for Broadcast and Multicast Service controller discovery in an IP network. Broadcast service is being developed for 3rd generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive broadcast service. Dynamic Host Configuration Protocol can be used to configure the MN to acccess a particular controller. This document defines the related options and option codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-bcmc-options-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-bcmc-options-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-bcmc-options-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-17154058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-bcmc-options-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-bcmc-options-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-17154058.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue May 17 16:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8lB-0002FL-77; Tue, 17 May 2005 16:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8l6-0002Ab-Cn; Tue, 17 May 2005 16:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15576; Tue, 17 May 2005 16:33:41 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8yl-0008RT-MS; Tue, 17 May 2005 16:47:52 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 16:30:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4HKToeM023740; Tue, 17 May 2005 16:30:17 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 16:30:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Tue, 17 May 2005 16:30:04 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B373A@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVahGdhDLV9JhwsRneDDXLPFEI82gAk6wCgAAD0MnA= From: "Bernie Volz \(volz\)" To: "timothy enos" , "Pekka Savola" X-OriginalArrivalTime: 17 May 2005 20:30:05.0206 (UTC) FILETIME=[35A53360:01C55B1F] X-Spam-Score: 1.1 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Pekka suggested you might have been referring to stateless DHCPv6 - ie, when does a DHCPv6 client doing stateful DHCPv6 switch to doing stateless DHCPv6? I don't believe we had any specific text in this regard in 3315 or 3736 and is thus likely an issue for 3315-bis. I assume you're asking this in the case where both the M and O flags are set? And, I can see three techniques: 1. If the client supports stateful always use stateful and never switch to stateless. 2. Try stateful for a few (perhaps only 1 Solicit / Advertise) cycles and if there are no responses or only "error" responses, continue stateful but also initiate stateless. The start of stateless could be controlled by the O flag. 2. Always start both. Personally, I like the first best as I would expect that if the M flag is set and no DHCPv6 server responds, sending Information-Request messages will also not yield anything useful. But, this does not work if the default were to always set the M and O bits in RAs but only have a stateless server. That's why I think we've made mistakes in the DHCPv6 specifications: 1. For 3315, we should have had a status return code for an Advertise that says "no stateful service available." Note that this is different than the NoAddrsAvail status we presently have.=20 2. For 3736, we should have required Solicit and Advertise to be supported by the stateless DHCPv6 server such that it could return just the "no stateful service available" status for any Solicits it receives. That way, if the only servers to respond to Solicits all return "no stateful service available", the client knows what to do. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bernie Volz (volz) > Sent: Tuesday, May 17, 2005 3:41 PM > To: timothy enos; Pekka Savola > Cc: dhcwg@ietf.org; JINMEI Tatuya / ????; IPv6 WG; Ralph=20 > Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Tim: >=20 > I'm not sure what you mean by your question ... SLAC (stateless > auto-configuration) is independent of stateful. There may be some > prefixes on a link that are stateful (0 or more) and others that are > stateless (0 or more - excluding the link-local which is always > stateless). >=20 > So, SLAC is independent of stateful (DHCPv6). >=20 > - Bernie >=20 > > -----Original Message----- > > From: timothy enos [mailto:timbeck04@verizon.net]=20 > > Sent: Monday, May 16, 2005 10:00 PM > > To: Bernie Volz (volz); 'Pekka Savola' > > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI=20 > > Tatuya / ????' > > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > >=20 > > Bernie, > > =09 > > Your points are well taken, and I agree. Making these flags 'hints' > > makes sense. Also, it seems that if a client does not know=20 > what to do > > (forgive the anthropomorphism) in response to having received=20 > > an RA with > > the M (and O) bit(s) set (because it is not a DHCPv6=20 > client), it would > > just ignore it/them.=20 > >=20 > > Also wondering if there are any RFC 3315-capable clients that, after > > failing to get config info from a DHCPv6 server 'x' times,=20 > > would revert > > to SLAC? > >=20 > > Tim Enos > > 1Sam16:7 > >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > Behalf Of > > Bernie Volz (volz) > > Sent: Monday, May 16, 2005 5:20 PM > > To: Pekka Savola > > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI=20 > > Tatuya / ???? > > Subject: RE: [dhcwg] Re: IPv6 WG Last > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > >=20 > > Hey, if they don't know what they're doing then set the bits=20 > > and be done > > with it. If there's no DHCP server, the clients will try to get > > configuration information and fail and continuously try in the > > background. That's the safest fallback and the recommended default, > > IMHO. > >=20 > > If they do set them wrong, it won't take long for users to complain. > > Just as they do now if the DHCP server or routing infrastructure is > > down. > >=20 > > Trying to design for stupidity only produces the same. > >=20 > > - Bernie=20 > >=20 > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > > > Sent: Monday, May 16, 2005 5:09 PM > > > To: Bernie Volz (volz) > > > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph=20 > > > Droms (rdroms) > > > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > >=20 > > > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > > > BTW, if you want to look at this from the router administrator's > > > > perspective: > > > > > > > > Configure the router to send the M flag set in routing=20 > > > advertisements > > > > for a Link IF: > > > > 1. A stateful DHCP server is deployed for that link=20 > > (either on it or > > > > reachable via a relay agent) AND > > >=20 > > > IMHO, you're making a significant leap of faith in assuming that=20 > > > whoever configures the router's M-flag advertisements has=20 > > sufficient=20 > > > clue to grasp the different semantics that arise with: > > >=20 > > > - M-flag and/or O-flag > > > - stateless and stateful clients > > > - stateless and stateful servers > > > - stateless and stateful relay agents > > >=20 > > > Hence, if we want to build a robust system, we need to=20 > > design it with=20 > > > care. > > >=20 > > >=20 > > >=20 > > > --=20 > > > Pekka Savola "You each name yourselves=20 > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A=20 > Clash of Kings > > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 18 04:10:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJdZ-0002WI-HF; Wed, 18 May 2005 04:10:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJdW-0002Vq-JI; Wed, 18 May 2005 04:10:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15917; Wed, 18 May 2005 04:10:36 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYJuM-0003ud-6U; Wed, 18 May 2005 04:28:07 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2912D15210; Wed, 18 May 2005 17:12:33 +0900 (JST) Date: Wed, 18 May 2005 17:11:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (volz)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: dhcwg@ietf.org, IPv6 WG , Pekka Savola , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Mon, 16 May 2005 09:56:26 -0400, >>>>> "Bernie Volz (volz)" said: > I haven't followed this thread carefully, but are you trying to suggest > that if the M flag is set but O is not, that a client would IGNORE the > other configuration parameters received from a DHCP server in a > Solicit/Advertise/Request/Reply sequence? Nope. Not at all. Perhaps I was just not very clear, but I basically agree with your understanding (and opinions) below (and so do all of us, I believe). In particular, - I didn't intend to *force* a host (client) to take a particular action. - I agree that the M or O flag is just a "hint" about available configuration methods. And, in fact, in draft-ietf-ipv6-ra-mo-flags-01.txt we do not use any "MUST" or "MUST NOT" with one exception which is actually a citation from another document. Also, we introduced separate "policy variables" for hosts so that they can act based on their own decision, regardless of the RA flags. What I was trying to address is to avoid an undesirable situation for hosts when not everything is perfectly working. For example, consider the case where we provide both address allocation via DHCPv6 and also the stateless service (the RFC3736 subset of DHCPV6) in a network. As you mentioned in a separate message, we can think of a scenario in which it makes sense for a host to use the information provided via the RFC3736 subset but not use address allocation via DHCPv6. In this case, both the M and O flags in RAs would be set to ON. Now, suppose that there is a reachability trouble from a host to all available DHCPv6 servers that provide the address allocation service, but some of the RFC3736 DHCPv6 servers can be reached (I think this can happen because the latter can be more lightweight. For example, some or all of routers in the host subnets would probably be able to act as the RFC3736 DHCPv6 server without offering any addresses to be allocated to the client). Or worse, there may be a configuration error that the router administrator sets the M flag ON while there is actually no address allocation service via DHCPv6 available. This is a special case of the above "reachable trouble". In such cases, if the host can still do meaningful operation (this can happen, as you pointed out in a separate message) even without being allocated global addresses via DHCPv6, it would want to get other configuration information via the available RFC3736 service. What I want to clarify in the draft-ietf-ipv6-ra-mo-flags-01.txt document is to provide operational guideline for hosts in such cases. Specifically, I proposed to explicitly allow the host to perform the address allocation exchanges and the RFC3736 exchange concurrently in that document. Someone may want to point out that such a behavior is not prohibited in RFC3315 and that we don't have to emphasize that in a separate document. But at least I was previously confused about whether this is a valid behavior, so I believe it makes sense to mention that explicitly. And finally, I admit the above examples can be an issue only when something unexpected happens (e.g., when the administrator misconfigures the router, or under a reachability problem). I personally still think it makes sense to provide a guideline so that the host can get as much configuration information as possible even under a small administrative error (again, I'm not intending to *force* a particular action for such cases). But if many others think this is too minor to mention the ra-mo-flags document explicitly, I'll follow that decision. Am I now clear enough? (I believe this response also covers the rest of the messages in this thread or some of the other messages talk about different things I intended to discuss, so I won't explicitly reply to the other messages for now. If I still miss something crucial in the other messages, please point it out.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp > That seems very bad to me. And > a waste of resources to have to do two sets of transactions > (Solicit/Advertise/Request/Reply for addresses and > Information-Request/Reply for other configuration). > I really don't understand why this issue has been so difficult to > resolve. > In IPv4, DHCP is often the default unless you explicitly configure an > interface or turn DHCP off. We don't have ANY network wide configuration > for this. And it works very well indeed. > In IPv6, the M and O flag should serve as hints. Period. A host is > perfectly free to do what it wants (or what it has been configured to > do). > The M flag, if set, means a host SHOULD do full-RFC 3315. This means > they should attempt to Solicit, but can also fall back to > Information-Request if needed. This means both addresses and other > configuration are configured, if available. > The O flag, if set, means a host SHOULD do RFC 3376 (partial RFC 3315). > If both flags are set, hosts that can do full RFC 3315 do it (and ignore > the O flag). Those that can only do RFC 3376, do that. > If no flag it set, hosts may still do RFC 3315 and/or 3376 if so > configured (whether by default or otherwise). There should be no > prohibition against doing that. The document need not say this - it is > implied because we MUST NOT use MUST or MUST NOT. Just SHOULD or SHOULD > NOT when taking about the bits. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 18 12:31:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRRn-0002uN-6X; Wed, 18 May 2005 12:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRRk-0002to-O2; Wed, 18 May 2005 12:31:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09520; Wed, 18 May 2005 12:30:55 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYRig-000091-He; Wed, 18 May 2005 12:48:32 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4IGUjMk031569; Wed, 18 May 2005 12:30:45 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4IGUjPE154700; Wed, 18 May 2005 12:30:45 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4IGUdUB006546; Wed, 18 May 2005 12:30:39 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-34-201.mts.ibm.com [9.48.34.201]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4IGUd0e006523; Wed, 18 May 2005 12:30:39 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4IGTKmt005705; Wed, 18 May 2005 12:29:20 -0400 Message-Id: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> To: "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: Message from "Bernie Volz \(volz\)" of "Mon, 16 May 2005 09:56:26 EDT." <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> Date: Wed, 18 May 2005 12:29:20 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , Pekka Savola X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Let me just start off by saying I pretty much agree completely with what Bernie just said. I've also reviewed this document, and I am really wondering what this document is trying to achieve. It seems to me that its added a lot of text (that IMO is not really needed). In particular, I don't think either Section 6 or 7 are necessary or appropriate. There are really only two behaviors a client should be doing. If a client doesn't implement DHC, well, then it obviously shouldn't/can't invoke DHC. End of story. If it does implement DHC, well, it should use it. Moreover, it shold never really be a "client" choice whether to invoke use DHC or not. If the sys admin has stuff available via DHC, the client should (in the SHOULD sense) be getting it and using it. Why on earth would we want to disable that via a configuration knob? Indeed, when I look at Section 2, "Background", I find that the wording that it quotes from RFC 2461 really does say pretty much what should be said. That is, these bits are "hints" that the local sys admin has a DHC server that is giving out addresses and/or other configuration information. Seems to me, if the local access network is giving out config information, clients SHOULD try and get it, because if they don't, they will presumably operate at some sort of reduced level of functionality -- after all, if a sys admin set up a DHC server, there must be a reason for this (e.g., to provide DNS recursive name server service, addresses not available via stateless addrconf, etc.). So, these bits should just provide clients with a stronger indication that they should be using DHC to get the information that is available. If the original 2461 text is really deemed insufficient, how about something like: o M : 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6], including addresses that were not configured via stateless address autoconfiguration. Clients SHOULD use DHC to obtain addresses (and associated configuration information) as described in [ADDRCONF]. Note that when the M bit is set, the setting of the O bit is irrelevant, since the DHC server will return "other" configuration information together with addresses. o O : 1-bit "Other configuration" flag. When set, it indicates that [DHCPv6lite] is available for autoconfiguration of other (non-address) information. Examples of such information are DNS-related information or information on other servers within the network. When set, - If the M bit is also set, clients SHOULD use DHC to obtain addresses (and associated configuration information) as described above. - If the M bit is not set, clients SHOULD use DHC as described in RFC 3736. Is more than something like the above _really_ needed? If so, why? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 19 00:47:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYcwV-00069R-CC; Thu, 19 May 2005 00:47:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYcwT-00066i-6F; Thu, 19 May 2005 00:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28600; Thu, 19 May 2005 00:47:25 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYdDY-0004yd-7F; Thu, 19 May 2005 01:05:08 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGP005NXZYTMC@mailout2.samsung.com>; Thu, 19 May 2005 13:47:17 +0900 (KST) Received: from SURAJKUMAR ([107.108.71.56]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IGP000MMZX9YZ@mmp2.samsung.com>; Thu, 19 May 2005 13:47:17 +0900 (KST) Date: Thu, 19 May 2005 10:14:33 +0530 From: Suraj Kumar To: dhcwg@ietf.org, pana@ietf.org Message-id: <012301c55c2d$925b5530$38476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/mixed; boundary="Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [dhcwg] Fw: I-D ACTION:draft-suraj-dhcpv4-paa-option-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-Transfer-Encoding: 7BIT This is to inform you that we have written a draft on " DHCPv4 option for PANA Authentication Agents (PAA)". Please review and send us comments. Suraj ----- Original Message ----- From: To: Sent: Thursday, May 19, 2005 1:15 AM Subject: I-D ACTION:draft-suraj-dhcpv4-paa-option-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : DHCPv4 option for PANA Authentication Agents > Author(s) : S. Kumar, et al. > Filename : draft-suraj-dhcpv4-paa-option-00.txt > Pages : 16 > Date : 2005-5-18 > > This document defines a new Dynamic Host Configuration Protocol > version 4 (DHCPv4) option that contains a list of domain names or > IPv4 addresses that can be mapped to one or more of PANA > Authentication Agents (PAA). This is one of the many methods that a > PANA Client (PaC) can use to locate PANA Authentication Agents (PAA). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-suraj-dhcpv4-paa-option-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-suraj-dhcpv4-paa-option-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-suraj-dhcpv4-paa-option-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-type: application/octet-stream; name=ATT00272.dat Content-disposition: attachment; filename=ATT00272.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-5-18154358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-suraj-dhcpv4-paa-option-00.txt --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-type: text/plain; format=flowed; name=draft-suraj-dhcpv4-paa-option-00.txt; reply-type=original Content-disposition: attachment; filename=draft-suraj-dhcpv4-paa-option-00.txt Content-Transfer-Encoding: 7BIT Content-Type: text/plain Content-ID: <2005-5-18154358.I-D@ietf.org> --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw)-- From pana-bounces@ietf.org Thu May 19 00:47:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYcwV-00069q-Pn; Thu, 19 May 2005 00:47:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYcwT-00066i-6F; Thu, 19 May 2005 00:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28600; Thu, 19 May 2005 00:47:25 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYdDY-0004yd-7F; Thu, 19 May 2005 01:05:08 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGP005NXZYTMC@mailout2.samsung.com>; Thu, 19 May 2005 13:47:17 +0900 (KST) Received: from SURAJKUMAR ([107.108.71.56]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IGP000MMZX9YZ@mmp2.samsung.com>; Thu, 19 May 2005 13:47:17 +0900 (KST) Date: Thu, 19 May 2005 10:14:33 +0530 From: Suraj Kumar To: dhcwg@ietf.org, pana@ietf.org Message-id: <012301c55c2d$925b5530$38476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/mixed; boundary="Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Pana] Fw: I-D ACTION:draft-suraj-dhcpv4-paa-option-00.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-Transfer-Encoding: 7BIT This is to inform you that we have written a draft on " DHCPv4 option for PANA Authentication Agents (PAA)". Please review and send us comments. Suraj ----- Original Message ----- From: To: Sent: Thursday, May 19, 2005 1:15 AM Subject: I-D ACTION:draft-suraj-dhcpv4-paa-option-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : DHCPv4 option for PANA Authentication Agents > Author(s) : S. Kumar, et al. > Filename : draft-suraj-dhcpv4-paa-option-00.txt > Pages : 16 > Date : 2005-5-18 > > This document defines a new Dynamic Host Configuration Protocol > version 4 (DHCPv4) option that contains a list of domain names or > IPv4 addresses that can be mapped to one or more of PANA > Authentication Agents (PAA). This is one of the many methods that a > PANA Client (PaC) can use to locate PANA Authentication Agents (PAA). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-suraj-dhcpv4-paa-option-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-suraj-dhcpv4-paa-option-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-suraj-dhcpv4-paa-option-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-type: application/octet-stream; name=ATT00272.dat Content-disposition: attachment; filename=ATT00272.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-5-18154358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-suraj-dhcpv4-paa-option-00.txt --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-type: text/plain; format=flowed; name=draft-suraj-dhcpv4-paa-option-00.txt; reply-type=original Content-disposition: attachment; filename=draft-suraj-dhcpv4-paa-option-00.txt Content-Transfer-Encoding: 7BIT Content-Type: text/plain Content-ID: <2005-5-18154358.I-D@ietf.org> --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana --Boundary_(ID_/4PTIITeLmhYy/N5zDPsTw)-- From dhcwg-bounces@ietf.org Thu May 19 14:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpOE-0006xb-4U; Thu, 19 May 2005 14:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpOC-0006xR-Pb for dhcwg@megatron.ietf.org; Thu, 19 May 2005 14:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00750 for ; Thu, 19 May 2005 14:04:55 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpfO-0001OC-GM for dhcwg@ietf.org; Thu, 19 May 2005 14:22:43 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 4EEDC200D7; Thu, 19 May 2005 14:04:46 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 25709-01; Thu, 19 May 2005 14:04:45 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id D242E200D4; Thu, 19 May 2005 14:04:45 -0400 (EDT) To: dhcwg@ietf.org, iana@iana.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Thu, 19 May 2005 14:07:09 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/19/2005 02:04:44 PM, Serialize complete at 05/19/2005 02:04:44 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0557275724==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============0557275724== Content-Type: multipart/alternative; boundary="=_alternative 00634F4885257006_=" This is a multipart message in MIME format. --=_alternative 00634F4885257006_= Content-Type: text/plain; charset="us-ascii" Hello DHC WG and IANA, Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned" list. Our usage is as follows. All are related to configuration of IP Phones (and similar devices) in a VoIP network. Option Usage ====== ===== 128 TFPT Server IP address (for IP Phone - specific sw load) 129 Call Server IP address 130 Discrimination string (to identify vendor) 131 Remote statistics server IP address 132 802.1P VLAN ID 133 802.1Q L2 Priority 134 Diffserv Code Point 135 HTTP Proxy for phone-specific applications Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are). Also, it is not completely clear whether an I-D documenting this same information is or is not required. We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods. Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options. Is an I-D required to complete the process of putting the options on the Tentatively Assigned list? While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state? Regards, Peter Blatherwick Sr. Solutions Architect, Mitel Networks --=_alternative 00634F4885257006_= Content-Type: text/html; charset="us-ascii"
Hello DHC WG and IANA,

Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned"  list.

Our usage is as follows.  All are related to configuration of IP Phones (and similar devices) in a VoIP network.

Option    Usage
======    =====
128       TFPT Server IP address (for IP Phone - specific sw load)
129       Call Server IP address
130       Discrimination string (to identify vendor)
131       Remote statistics server IP address
132       802.1P VLAN ID
133       802.1Q L2 Priority
134       Diffserv Code Point
135       HTTP Proxy for phone-specific applications


Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are).

Also, it is not completely clear whether an I-D documenting this same information is or is not required.  We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods.  Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options.  Is an I-D required to complete the process of putting the options on the Tentatively Assigned list?  

While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state?  

Regards,
Peter Blatherwick
Sr. Solutions Architect,
Mitel Networks
--=_alternative 00634F4885257006_=-- --===============0557275724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0557275724==-- From dhcwg-bounces@ietf.org Thu May 19 14:07:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpQv-0007Xb-3X; Thu, 19 May 2005 14:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYpQt-0007XW-0M for dhcwg@megatron.ietf.org; Thu, 19 May 2005 14:07:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01101 for ; Thu, 19 May 2005 14:07:41 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYpi5-0001T2-Gi for dhcwg@ietf.org; Thu, 19 May 2005 14:25:30 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 6F45920105; Thu, 19 May 2005 14:07:33 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 26039-02; Thu, 19 May 2005 14:07:33 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 079D1200F0; Thu, 19 May 2005 14:07:33 -0400 (EDT) To: dhcwg@ietf.org, iana@iana.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Thu, 19 May 2005 14:09:56 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/19/2005 02:07:31 PM, Serialize complete at 05/19/2005 02:07:31 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1110456043==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1110456043== Content-Type: multipart/alternative; boundary="=_alternative 0063907C85257006_=" This is a multipart message in MIME format. --=_alternative 0063907C85257006_= Content-Type: text/plain; charset="us-ascii" [ sorry, resend to add a subject for tracking... please ignore previous ] Hello DHC WG and IANA, Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned" list. Our usage is as follows. All are related to configuration of IP Phones (and similar devices) in a VoIP network. Option Usage ====== ===== 128 TFPT Server IP address (for IP Phone - specific sw load) 129 Call Server IP address 130 Discrimination string (to identify vendor) 131 Remote statistics server IP address 132 802.1P VLAN ID 133 802.1Q L2 Priority 134 Diffserv Code Point 135 HTTP Proxy for phone-specific applications Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are). Also, it is not completely clear whether an I-D documenting this same information is or is not required. We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods. Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options. Is an I-D required to complete the process of putting the options on the Tentatively Assigned list? While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state? Regards, Peter Blatherwick Sr. Solutions Architect, Mitel Networks --=_alternative 0063907C85257006_= Content-Type: text/html; charset="us-ascii"
[ sorry, resend to add a subject for tracking...  please ignore previous ]

Hello DHC WG and IANA,

Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned"  list.

Our usage is as follows.  All are related to configuration of IP Phones (and similar devices) in a VoIP network.

Option    Usage
======    =====
128       TFPT Server IP address (for IP Phone - specific sw load)
129       Call Server IP address
130       Discrimination string (to identify vendor)
131       Remote statistics server IP address
132       802.1P VLAN ID
133       802.1Q L2 Priority
134       Diffserv Code Point
135       HTTP Proxy for phone-specific applications


Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are).

Also, it is not completely clear whether an I-D documenting this same information is or is not required.  We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods.  Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options.  Is an I-D required to complete the process of putting the options on the Tentatively Assigned list?  

While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state?  

Regards,
Peter Blatherwick
Sr. Solutions Architect,
Mitel Networks
--=_alternative 0063907C85257006_=-- --===============1110456043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1110456043==-- From dhcwg-bounces@ietf.org Thu May 19 18:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtiM-0001J8-Uk; Thu, 19 May 2005 18:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtiL-0001FY-9f for dhcwg@megatron.ietf.org; Thu, 19 May 2005 18:42:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10854 for ; Thu, 19 May 2005 18:41:58 -0400 (EDT) Received: from mail.acmeps.com ([216.17.167.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYtzZ-00057C-JK for dhcwg@ietf.org; Thu, 19 May 2005 18:59:50 -0400 Received: from [10.254.50.125] (m010f36d0.tmodns.net [208.54.15.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acmeps.com (Postfix) with ESMTP id C583B47D87; Thu, 19 May 2005 16:41:55 -0600 (MDT) Message-ID: <428D1633.5080906@acmeps.com> Date: Thu, 19 May 2005 16:41:55 -0600 From: Michael Milligan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon Subject: Re: [dhcwg] Discussion on draft-ietf-dhc-failover-12.txt [new rev?] References: <20050125004641.GL95006@isc.org> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted Lemon wrote: > On Jan 24, 2005, at 5:46 PM, David W. Hankins wrote: > >> It seems we would at least like to know how much interest there was for >> this within the WG still. > > I would very much like to see this draft advance, as I'm sure would a > number of other people. Very much agreed. What is the status of the failover draft? Has there been a rev recently? I thought it went to IESG... Anyway, I can't find -12 or -13 anywhere now because they have expired. Regards, Mike -- Michael Milligan -> milli@acmeps.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 19 18:45:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtlp-0002jv-OK; Thu, 19 May 2005 18:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtlk-0002j3-CQ; Thu, 19 May 2005 18:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11237; Thu, 19 May 2005 18:45:29 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYu2y-0005CR-H2; Thu, 19 May 2005 19:03:21 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4JME6N01863; Thu, 19 May 2005 15:14:06 -0700 X-mProtect: <200505192214> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdxf0MSc; Thu, 19 May 2005 15:14:05 PDT Message-Id: <6.2.1.2.2.20050519154211.02c678a8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 19 May 2005 15:45:04 -0700 To: Thomas Narten From: Bob Hinden Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> References: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dhcwg@ietf.org, IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thomas, >If the original 2461 text is really deemed insufficient, how about >something like: > > o M : > > 1-bit "Managed address configuration" flag. When set, it > indicates that addresses are available via Dynamic Host > Configuration Protocol [DHCPv6], including addresses that were > not configured via stateless address autoconfiguration. Clients > SHOULD use DHC to obtain addresses (and associated > configuration information) as described in [ADDRCONF]. Note > that when the M bit is set, the setting of the O bit is > irrelevant, since the DHC server will return "other" > configuration information together with addresses. > > o O : > > 1-bit "Other configuration" flag. When set, it indicates that > [DHCPv6lite] is available for autoconfiguration of other > (non-address) information. Examples of such information are > DNS-related information or information on other servers within > the network. When set, > > - If the M bit is also set, clients SHOULD use DHC to obtain > addresses (and associated configuration information) as > described above. > > - If the M bit is not set, clients SHOULD use DHC as > described in RFC 3736. > > >Is more than something like the above _really_ needed? If so, why? I agree and also don't see why more than this is needed. Thanks, Bob _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 19 19:01:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYu1Y-00019X-J6; Thu, 19 May 2005 19:01:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYu1X-00019O-6a for dhcwg@megatron.ietf.org; Thu, 19 May 2005 19:01:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13138 for ; Thu, 19 May 2005 19:01:48 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYuIl-0005jE-I7 for dhcwg@ietf.org; Thu, 19 May 2005 19:19:40 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id DFEBFB240B; Thu, 19 May 2005 16:01:33 -0700 (PDT) Date: Thu, 19 May 2005 16:01:33 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Discussion on draft-ietf-dhc-failover-12.txt [new rev?] Message-ID: <20050519230133.GD58871@isc.org> References: <20050125004641.GL95006@isc.org> <428D1633.5080906@acmeps.com> Mime-Version: 1.0 In-Reply-To: <428D1633.5080906@acmeps.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0006105917==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0006105917== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SO98HVl1bnMOfKZd" Content-Disposition: inline --SO98HVl1bnMOfKZd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 19, 2005 at 04:41:55PM -0600, Michael Milligan wrote: > What is the status of the failover draft? Has there been a rev=20 > recently? I thought it went to IESG... Anyway, I can't find -12 or -13= =20 > anywhere now because they have expired. Expired but not forgotten. I believe -12 is still the most recent revisison. Hopefully it's not bad form for me to send you the document under separate copy. For my part, I've promised several parties I would have additional comments after completing some implementation changes (our implementation was last measured against revision 7 as near as I can tell). Unfortunately I've had some other 'surprise' workloads to attend to. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --SO98HVl1bnMOfKZd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCjRrNcXeLeWu2vmoRAtzJAKCAhmsSQmcRpBsRb3O14/5by8o73ACfbPAs mIKqLRYRZ71QHeBSrpm4h5Y= =JAh5 -----END PGP SIGNATURE----- --SO98HVl1bnMOfKZd-- --===============0006105917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0006105917==-- From dhcwg-bounces@ietf.org Thu May 19 22:52:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYxcM-0004vH-4G; Thu, 19 May 2005 22:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYxcK-0004v6-EL for dhcwg@megatron.ietf.org; Thu, 19 May 2005 22:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03318 for ; Thu, 19 May 2005 22:52:01 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYxta-0002zu-SV for dhcwg@ietf.org; Thu, 19 May 2005 23:09:56 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 19 May 2005 23:02:37 -0400 X-IronPort-AV: i="3.93,122,1115006400"; d="scan'208"; a="50276181:sNHT29842760" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4K2panU028746; Thu, 19 May 2005 22:51:52 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 22:51:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Discussion on draft-ietf-dhc-failover-12.txt [new rev?] Date: Thu, 19 May 2005 22:51:45 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3C0A@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Discussion on draft-ietf-dhc-failover-12.txt [new rev?] Thread-Index: AcVcxyrn7Klqo+x+SJK8kNQnFKMMCAAHzIxg From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 20 May 2005 02:51:46.0880 (UTC) FILETIME=[DCEED400:01C55CE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph was reviewing it and came up with a bunch of comments. While many were cleaning up terminology (consistent usage, etc) and wording, there were a few more complex issues. I don't think Kim's worked those into a new version of the draft. -12 was the latest as best I can determine. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of David W. Hankins > Sent: Thursday, May 19, 2005 7:02 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Discussion on=20 > draft-ietf-dhc-failover-12.txt [new rev?] >=20 > On Thu, May 19, 2005 at 04:41:55PM -0600, Michael Milligan wrote: > > What is the status of the failover draft? Has there been a rev=20 > > recently? I thought it went to IESG... Anyway, I can't=20 > find -12 or -13=20 > > anywhere now because they have expired. >=20 > Expired but not forgotten. I believe -12 is still the most recent > revisison. Hopefully it's not bad form for me to send you=20 > the document > under separate copy. >=20 >=20 > For my part, I've promised several parties I would have additional > comments after completing some implementation changes (our=20 > implementation > was last measured against revision 7 as near as I can tell). >=20 > Unfortunately I've had some other 'surprise' workloads to attend to. >=20 > --=20 > David W. Hankins "If you don't do it right the=20 > first time, > Software Engineer you'll just have to do=20 > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 19 23:00:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYxkB-0006gf-M6; Thu, 19 May 2005 23:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYxk7-0006gO-OF for dhcwg@megatron.ietf.org; Thu, 19 May 2005 23:00:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04132 for ; Thu, 19 May 2005 23:00:04 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYy1O-0003CK-I8 for dhcwg@ietf.org; Thu, 19 May 2005 23:17:59 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 19 May 2005 23:10:41 -0400 X-IronPort-AV: i="3.93,122,1115006400"; d="scan'208,217"; a="50276904:sNHT44954964" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4K2xoe2007910; Thu, 19 May 2005 22:59:55 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 22:59:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Thu, 19 May 2005 22:59:50 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3C0B@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVcnekPtkIqf8sCS56lT9TbpxeC3AASQWAQ From: "Bernie Volz \(volz\)" To: , , X-OriginalArrivalTime: 20 May 2005 02:59:53.0514 (UTC) FILETIME=[FEFD48A0:01C55CE7] X-Spam-Score: 0.9 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507101055==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1507101055== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55CE7.FEDB2908" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55CE7.FEDB2908 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks Peter. =20 I assume your usage of these option numbers has nothing to do with PXE. =20 Regarding the I-D, yes it would be useful to have that. But as there are conflicting uses of these option numbers, moving away from their use is highly recommended. So, it is up to you. =20 The I-D would be to document the existing usage. =20 If you make use of the RFC 3925 vendor options going forward, that would mean you would not need to standardize the new options via the IETF. =20 Yes, there will be a list. I am waiting until early June to compile that as I wanted to give people until the end of May to respond. I expect to send it to IANA and hopefully they'll publish that on the DHCPv4 options page. =20 This list will primarily indicate the options that are in use, but I don't expect to give details of the data format, etc. That is what future I-Ds will hopefully do.=20 =20 - Bernie ________________________________ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of peter_blatherwick@mitel.com Sent: Thursday, May 19, 2005 2:10 PM To: dhcwg@ietf.org; iana@iana.org Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 =09 [ sorry, resend to add a subject for tracking... please ignore previous ]=20 =09 Hello DHC WG and IANA,=20 =09 Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned" list.=20 =09 Our usage is as follows. All are related to configuration of IP Phones (and similar devices) in a VoIP network.=20 =09 Option Usage=20 =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=20 128 TFPT Server IP address (for IP Phone - specific sw load)=20 129 Call Server IP address=20 130 Discrimination string (to identify vendor)=20 131 Remote statistics server IP address=20 132 802.1P VLAN ID=20 133 802.1Q L2 Priority=20 134 Diffserv Code Point=20 135 HTTP Proxy for phone-specific applications=20 =09 =09 Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are).=20 =09 Also, it is not completely clear whether an I-D documenting this same information is or is not required. We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods. Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options. Is an I-D required to complete the process of putting the options on the Tentatively Assigned list? =20 =09 While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state? =20 =09 Regards,=20 Peter Blatherwick=20 Sr. Solutions Architect,=20 Mitel Networks=20 =09 ------_=_NextPart_001_01C55CE7.FEDB2908 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Thanks Peter.
 
I assume your usage of these option numbers has = nothing to=20 do with PXE.
 
Regarding the I-D, yes it would be useful to = have that. But=20 as there are conflicting uses of these option numbers, moving away = from=20 their use is highly recommended. So, it is up to = you.
 
The I-D would be to document the existing=20 usage.
 
If you make use of the RFC 3925 vendor options = going=20 forward, that would mean you would not need to standardize the new=20 options via the IETF.
 
Yes, there will be a list. I am waiting = until early=20 June to compile that as I wanted to give people until the end of May to = respond.=20 I expect to send it to IANA and hopefully they'll publish that on the = DHCPv4=20 options page.
 
This list will primarily indicate the = options that are=20 in use, but I don't expect to give details of the data format, etc. That = is what=20 future I-Ds will hopefully do. 
 
- Bernie

From: dhcwg-bounces@ietf.org=20 [mailto:dhcwg-bounces@ietf.org] On Behalf Of=20 peter_blatherwick@mitel.com
Sent: Thursday, May 19, 2005 = 2:10=20 PM
To: dhcwg@ietf.org; iana@iana.org
Subject: = [dhcwg] DHCP=20 options 128-135 in use -- please place on "Tentatively Assigned" list = re. RFC=20 3942


[ = sorry, resend=20 to add a subject for tracking...  please ignore previous ] =

Hello DHC WG and IANA,=20

Regarding RFC 3942, = this is to=20 document our (Mitel Networks) use of DHCP options 128-135 in the = current=20 vendor-specific range, and to request these be placed on the = "Tentatively=20 Assigned"  list.

Our usage is=20 as follows.  All are related to configuration of IP Phones (and = similar=20 devices) in a VoIP network.

Option    Usage
=3D=3D=3D=3D=3D=3D    =3D=3D=3D=3D=3D =
128       TFPT Server IP address (for IP Phone = -=20 specific sw load)
129 =    =20   Call Server IP address
130=20       Discrimination string (to identify vendor) =
131       = Remote statistics=20 server IP address
132 =    =20   802.1P VLAN ID
133  =20     802.1Q L2 Priority
134       Diffserv Code Point
135       HTTP Proxy for=20 phone-specific applications


Please confirm that these will go on the Tentatively Assigned = list (or=20 perhaps some already are).

Also,=20 it is not completely clear whether an I-D documenting this same = information is=20 or is not required.  We are currently looking at getting away = from this=20 scheme, in favor of better defined / standardized vendor-specific = methods.=20  Given this, and the high likelihood of clashes over the same = options=20 wanted for use by others, we do not currently intend to pursue = standardization=20 of these options.  Is an I-D required to complete the process of = putting=20 the options on the Tentatively Assigned list?   =

While we're on it, is there already, or = will there be,=20 a definitive list of all the options in Tentatively Assigned state? =  =20

Regards, =
Peter Blatherwick
Sr. Solutions Architect,
Mitel=20 Networks
------_=_NextPart_001_01C55CE7.FEDB2908-- --===============1507101055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1507101055==-- From dhcwg-bounces@ietf.org Fri May 20 03:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1mO-0001iK-Pl; Fri, 20 May 2005 03:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1mI-0001hR-Na; Fri, 20 May 2005 03:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14518; Fri, 20 May 2005 03:18:37 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ23c-0000sd-4h; Fri, 20 May 2005 03:36:32 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 44F5215218; Fri, 20 May 2005 16:20:50 +0900 (JST) Date: Fri, 20 May 2005 16:19:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (Cleaning the Cc list a bit) >>>>> On Wed, 18 May 2005 12:29:20 -0400, >>>>> Thomas Narten said: > There are really only two behaviors a client should be doing. If a > client doesn't implement DHC, well, then it obviously shouldn't/can't > invoke DHC. End of story. If it does implement DHC, well, it should > use it. Moreover, it shold never really be a "client" choice whether > to invoke use DHC or not. If the sys admin has stuff available via > DHC, the client should (in the SHOULD sense) be getting it and using > it. Why on earth would we want to disable that via a configuration > knob? One possible case would be a server host which manually configures itself with an IPv6 address, but seeks to get default router addresses via an RA and possibly other configuration information such as recursive DNS server addresses via DHCPv6 (Information-request/Reply). Such a host would receive (and use) RAs but not invoke DHCPv6 for address allocation even if the M flag is set in the RAs. I personally also expect a host that does not implement address allocation via DHCPv6 would have an implicit local policy that "disables" the behavior (regardless of the value of the M flag). But I admit the current mo-flags document does not clearly indicate that even if my expectation is reasonable. On the other hand, I'd also like to allow a client to use DHCPv6 (either full 3315 or the 3736 subset) even if the corresponding M or O flag is not set. In particular, I'd reserve the possibility for a host to try the RFC3736 behavior even if the O flag is off, so that the host can get configuration information even when the RA flags and available DHCPv6 are inconsistent (due to misconfiguration of routers, etc). > So, these bits should just provide clients with a stronger indication > that they should be using DHC to get the information that is > available. In general, I agree (while I'd say "...that they can be using DHC ..."). > Is more than something like the above _really_ needed? If so, why? "_really_" sounds subjective, and opinions may vary, but I personally don't think "the above" is enough in practice. In my understanding, many people have been confused about the relationship between the M/O flags and the "stateful" configuration protocol (we now know the protocol is DHCPv6). At least I, as an implementor, have been always confused about these points. For example, 1. whether the specification about the M flag indicates address allocation via DHCPv6 is a mandatory feature to be implemented in hosts. (this point may now be clear by the "IPv6 Node Requirements" document and recent clarification of 2462bis) 2. whether it's valid for a host to not invoke DHCPv6 (either full RFC3315 or the RFC3736 subset) even if the corresponding M/O flag is set. (see above) 3. whether it's valid for a host to do invoke DHCPv6 (either full RFC3315 or the RFC3736 subset) even if the corresponding M/O flag is not set. (see also above) 4. what should the host do if the M or O flag is reset from ON to OFF. (while I pernsoally believe RFC2462 is pretty clear on this, many people, including a DHCPv6 specialist, have still misunderstood that.) 5. what if the M flag is set but the host does not get any DHCPv6 Advertise in the initial exchange? Is it okay to fall back to the RFC3736 subset? Or is it even okay to run both full RFC3315 and the RFC3736 subset concurrently from the beginning? If all we have is "the above" you suggested or the current 2461bis wording, I'd still continue getting confused. So I personally want to clarify these points somewhere, either in an existing document or a separate document like the ra-mo-flags draft. As for the latter, I don't stick to the current content. Perhaps sections 6 and 7 are overspecification, and I'll be happy as long as we can clarify the points that have confused many people so far. According to the others' opinions, however, all or some of the above points seem to be so trivial to some people that they don't bother to "clarify" those. If I've been simply dull and things are so clear for others, I don't mind killing the new clarification document (it would reduce my responsibility:-). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 04:25:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2pL-0000BP-FC; Fri, 20 May 2005 04:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2pG-00009Y-6E; Fri, 20 May 2005 04:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19701; Fri, 20 May 2005 04:25:43 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ36Z-0002gw-Hk; Fri, 20 May 2005 04:43:40 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGS00GU24QM67@mailout2.samsung.com>; Fri, 20 May 2005 17:25:34 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IGS0043D4QC0H@mmp1.samsung.com>; Fri, 20 May 2005 17:25:34 +0900 (KST) Date: Fri, 20 May 2005 13:53:34 +0530 From: Syam Madanapalli Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt To: Thomas Narten Message-id: <008701c55d15$3c287d30$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 5/18/05, Thomas Narten wrote: > Let me just start off by saying I pretty much agree completely with > what Bernie just said. Even I do agrre, what Bernie said. I understodd from his mail, a node can fall back to Information Configuration Behavior (DHCPv6 Lite) if ti fails do Full DHCP. I am not sure if such infomation is available in handy somewhere. Moreless the draft looks similar to what Bernie said except with more options to control the invoking th DHCPv6 behaviour, e.g., If I know prettty sure that the DHCPv6 is not avaialble in the network my node is connected, I have not seen any reason why I should let DHCPv6 be running in the background. > > I've also reviewed this document, and I am really wondering what this > document is trying to achieve. It seems to me that its added a lot of > text (that IMO is not really needed). In particular, I don't think > either Section 6 or 7 are necessary or appropriate. > > There are really only two behaviors a client should be doing. If a > client doesn't implement DHC, well, then it obviously shouldn't/can't > invoke DHC. End of story. If it does implement DHC, well, it should > use it. Moreover, it shold never really be a "client" choice whether > to invoke use DHC or not. If the sys admin has stuff available via > DHC, the client should (in the SHOULD sense) be getting it and using > it. Why on earth would we want to disable that via a configuration > knob? If it is this simple, we do not really need the M/O flags in Router Advertisements. > > Indeed, when I look at Section 2, "Background", I find that the > wording that it quotes from RFC 2461 really does say pretty much what > should be said. That is, these bits are "hints" that the local sys > admin has a DHC server that is giving out addresses and/or other > configuration information. Seems to me, if the local access network is > giving out config information, clients SHOULD try and get it, because > if they don't, they will presumably operate at some sort of reduced > level of functionality -- after all, if a sys admin set up a DHC > server, there must be a reason for this (e.g., to provide DNS > recursive name server service, addresses not available via stateless > addrconf, etc.). Also it is not clear for nodes what they should if they receive these bits ON to OFF and vise versa. > > So, these bits should just provide clients with a stronger indication > that they should be using DHC to get the information that is > available. > > > If the original 2461 text is really deemed insufficient, how about > something like: > > o M : > > 1-bit "Managed address configuration" flag. When set, it > indicates that addresses are available via Dynamic Host > Configuration Protocol [DHCPv6], including addresses that were > not configured via stateless address autoconfiguration. Clients > SHOULD use DHC to obtain addresses (and associated > configuration information) as described in [ADDRCONF]. Note > that when the M bit is set, the setting of the O bit is > irrelevant, since the DHC server will return "other" > configuration information together with addresses. > > o O : > > 1-bit "Other configuration" flag. When set, it indicates that > [DHCPv6lite] is available for autoconfiguration of other > (non-address) information. Examples of such information are > DNS-related information or information on other servers within > the network. When set, > > - If the M bit is also set, clients SHOULD use DHC to obtain > addresses (and associated configuration information) as > described above. > > - If the M bit is not set, clients SHOULD use DHC as > described in RFC 3736. > > > Is more than something like the above _really_ needed? If so, why? Currently for IPv4, we either select to get the address using DHCP, or configure manually. At least this true in Windows OS. Similarly, it is not bad idea to have options for IPv6 to select between DHCPv6, SLAAC or Manual or combination of these. For an intelligent use he can furthe select options for DHCPv6 either to run all the time or run only when host sees the M/O flag set. THis is what the policy the draft is talking about. Of course I do agree that it it little heavy in the current form, which can be simplified. I think it is worth clarifing these, and in any case the draft is not going to introduce any changes to the existing standards. > > Thomas > > _______________________________________________ > 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-bounces@ietf.org Fri May 20 06:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ50Y-0000NQ-LV; Fri, 20 May 2005 06:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ50U-0000LB-G7; Fri, 20 May 2005 06:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29329; Fri, 20 May 2005 06:45:27 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ5Hp-0005lc-Of; Fri, 20 May 2005 07:03:26 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 May 2005 03:45:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4KAjFnE027792; Fri, 20 May 2005 03:45:18 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 06:45:17 -0400 Received: from 10.86.242.191 ([10.86.242.191]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 10:45:16 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 06:45:37 -0400 Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt From: Ralph Droms To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2005 06:37:55 -0400 Message-Id: <1116585475.7812.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 10:45:17.0351 (UTC) FILETIME=[02E4AB70:01C55D29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Comments in line... - Ralph On Fri, 2005-05-20 at 16:19 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > (Cleaning the Cc list a bit) >=20 > >>>>> On Wed, 18 May 2005 12:29:20 -0400,=20 > >>>>> Thomas Narten said: >=20 > > There are really only two behaviors a client should be doing. If a > > client doesn't implement DHC, well, then it obviously shouldn't/can't > > invoke DHC. End of story. If it does implement DHC, well, it should > > use it. Moreover, it shold never really be a "client" choice whether > > to invoke use DHC or not. If the sys admin has stuff available via > > DHC, the client should (in the SHOULD sense) be getting it and using > > it. Why on earth would we want to disable that via a configuration > > knob? >=20 > One possible case would be a server host which manually configures > itself with an IPv6 address, but seeks to get default router addresses > via an RA and possibly other configuration information such as > recursive DNS server addresses via DHCPv6 (Information-request/Reply). > Such a host would receive (and use) RAs but not invoke DHCPv6 for > address allocation even if the M flag is set in the RAs. There's no particular reason why a host with an otherwise configured address might not also use DHCP for other assigned addresses. But, I agree with you that use of DHCP in a host is a matter of local policy, perhaps guided by the M/O bits. > I personally also expect a host that does not implement address > allocation via DHCPv6 would have an implicit local policy that > "disables" the behavior (regardless of the value of the M flag). But > I admit the current mo-flags document does not clearly indicate that > even if my expectation is reasonable. This local policy seems to be a crucial issue. Do we try to describe host behavior explicitly or do we specify the network behavior (M/O bits; retransmit behavior for ND and DHCP; HCB/ICB (Host Configuration Behavior [RFC 3315]/Information Configuration Behavior [RFC 3736] information returned from DHCP server) and leave the host to implement its own policy and behavior? > On the other hand, I'd also like to allow a client to use DHCPv6 > (either full 3315 or the 3736 subset) even if the corresponding M or O > flag is not set. In particular, I'd reserve the possibility for a > host to try the RFC3736 behavior even if the O flag is off, so that > the host can get configuration information even when the RA flags and > available DHCPv6 are inconsistent (due to misconfiguration of routers, > etc). I don't see a reason to prohibit explicitly use of DHCP is M/O bits are not set. Other standards bodies or host implementors may choose to make such prohibitions if appropriate; e.g., in a network environment with limited bandwidth where any spurious traffic is avoided. > > So, these bits should just provide clients with a stronger indication > > that they should be using DHC to get the information that is > > available. >=20 > In general, I agree (while I'd say "...that they can be using DHC > ..."). >=20 > > Is more than something like the above _really_ needed? If so, why? >=20 > "_really_" sounds subjective, and opinions may vary, but I personally > don't think "the above" is enough in practice. In my understanding, > many people have been confused about the relationship between the M/O > flags and the "stateful" configuration protocol (we now know the > protocol is DHCPv6). At least I, as an implementor, have been always > confused about these points. For example, >=20 > 1. whether the specification about the M flag indicates address > allocation via DHCPv6 is a mandatory feature to be implemented in > hosts. (this point may now be clear by the "IPv6 Node > Requirements" document and recent clarification of 2462bis) I agree that the requirement for DHCP has never been entirely clear nor well-documented. > 2. whether it's valid for a host to not invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is set. (see above) > 3. whether it's valid for a host to do invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is not set. (see also above) If there is confusion about these points, then we need clarification, once we agree on the desired behavior and definition. > 4. what should the host do if the M or O flag is reset from ON to OFF. > (while I pernsoally believe RFC2462 is pretty clear on this, many > people, including a DHCPv6 specialist, have still misunderstood > that.) RFC 2462 is pretty clear; however, I must admit I have been confused by the lengthy discussion clarifying the meaning of the bits and I seem to remember that there was a proposal to change the meaning of the bits at some point in the discussion. > 5. what if the M flag is set but the host does not get any DHCPv6 > Advertise in the initial exchange? Is it okay to fall back to the > RFC3736 subset? Or is it even okay to run both full RFC3315 and > the RFC3736 subset concurrently from the beginning? There is another possibility - a DHCP server that will not assign addresses can respond to a Solicit message with an appropriate status code. Thus, a host that tries to use HCB first can get an immediate indication that HCB is not available and revert to ICB immediately. Deployment of such behavior may require some clarification in the DHCP RFCs, because the existence of two separate RFCs has led to confusion about the "separation" of two "different" protocols for HCB and ICB. There is no *prohibition* against a DHCP server that intends to participate only in ICB from responding to a Solicit message with the "will not assign addresses" ("NoAddrsAvail")._DOa. Additionally, a small, backward-compatible extension to RFC 3315 would simplify the situation even further. At present, RFC 3315 specifies that a server return the NoAddrsAvail status code and no other information. If the server were allowed to return NoAddrsAvail *and* ICB options, the host could use the ICB options with a simple 2-message exchange. This extension would also require a clarification to RFC 3736 explicitly allowing this behavior (Note that RFC 3736 is intended as *minimum* function and does not *prohibit* implementation of other DHCP features). > If all we have is "the above" you suggested or the current 2461bis > wording, I'd still continue getting confused. So I personally want to > clarify these points somewhere, either in an existing document or a > separate document like the ra-mo-flags draft. As for the latter, I > don't stick to the current content. Perhaps sections 6 and 7 are > overspecification, and I'll be happy as long as we can clarify the > points that have confused many people so far. >=20 > According to the others' opinions, however, all or some of the above > points seem to be so trivial to some people that they don't bother to > "clarify" those. If I've been simply dull and things are so clear for > others, I don't mind killing the new clarification document (it would > reduce my responsibility:-). >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp In my opinion, we need a simple clarification of M/O bits as "advisory" and that there is no explicit *restriction* on hosts' use of DHCP. We might also consider a couple of clarifications and minor extensions to the DHCP spec to optimize host-server interaction. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 07:39:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ5qU-0002w9-Iq; Fri, 20 May 2005 07:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ5qS-0002va-0b; Fri, 20 May 2005 07:39:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03397; Fri, 20 May 2005 07:39:10 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ67o-000719-3H; Fri, 20 May 2005 07:57:08 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 07:39:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KBcQeS004160; Fri, 20 May 2005 07:39:00 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 07:38:59 -0400 Received: from 10.86.242.191 ([10.86.242.191]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 11:38:59 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 07:39:19 -0400 Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt From: Ralph Droms To: dhcwg@ietf.org, IPv6 WG In-Reply-To: References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 07:39:19 -0400 Message-Id: <1116589159.7812.70.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 11:38:59.0747 (UTC) FILETIME=[83974730:01C55D30] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The discussion of M/O bits caused me to think about the meaning and specification of host behavior for M/O bits and for SLAAC. In particular, I'm trying to understand the degree of control over host behavior specified in both cases. I'll focus here on what I can understand about SLAAC, because we've been discussing the M/O bits in a separate thread. One part of the specification in section 5.5 of RFC 2462 seems pretty clear: 5.5. Creation of Global and Site-Local Addresses [...] Creation of global and site-local addresses and configuration of other parameters as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default. I read this to mean that the information in the RAs is advisory. In section 5.5.3 of RFC 2462, the following text seems to imply that the "autonomous address-configuration flag" (A bit) controls whether a host forms a SLAAC address for a prefix: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. But, there is no RFC 2119 language, and the earlier text allows for local host configuration, so it's not clear if a host is compliant with RFC 2462 if it forms a SLAAC address from a prefix advertised with the A-bit not set. Later in the same list of behaviors: d) If the prefix advertised does not match the prefix of an address already in the list, and the Valid Lifetime is not 0, form an address (and add it to the list) [...] This text also does not contain RFC 2119 language, so it's not clear that a host is required to form an SLAAC address from a prefix advertised with the A-bit set. While open to interpretation, I read the text about SLAAC addresses to be advisory, which would give roughly the same control over host behavior as interpreting the M/O bits as indicating the availability of DHCP services, but not requiring specific behavior on the part of hosts. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 10:02:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ85L-0001N7-Ve; Fri, 20 May 2005 10:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ85K-0001N2-65 for dhcwg@megatron.ietf.org; Fri, 20 May 2005 10:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18288 for ; Fri, 20 May 2005 10:02:40 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8Mg-0002f0-00 for dhcwg@ietf.org; Fri, 20 May 2005 10:20:39 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 35BD7200E2; Fri, 20 May 2005 10:02:31 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 01470-04-2; Fri, 20 May 2005 10:02:30 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 9ABAD2008A; Fri, 20 May 2005 10:02:30 -0400 (EDT) To: "Bernie Volz (volz)" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Fri, 20 May 2005 10:04:55 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/20/2005 10:02:29 AM, Serialize complete at 05/20/2005 10:02:29 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 1.2 (+) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: dhcwg@ietf.org, iana@iana.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1794921678==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1794921678== Content-Type: multipart/alternative; boundary="=_alternative 004D1D9485257007_=" This is a multipart message in MIME format. --=_alternative 004D1D9485257007_= Content-Type: text/plain; charset="us-ascii" Thanks Bernie, Will generate the I-D. No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well. We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-) -- Peter "Bernie Volz (volz)" 19.05.05 22:59 To: , , cc: Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thanks Peter. I assume your usage of these option numbers has nothing to do with PXE. Regarding the I-D, yes it would be useful to have that. But as there are conflicting uses of these option numbers, moving away from their use is highly recommended. So, it is up to you. The I-D would be to document the existing usage. If you make use of the RFC 3925 vendor options going forward, that would mean you would not need to standardize the new options via the IETF. Yes, there will be a list. I am waiting until early June to compile that as I wanted to give people until the end of May to respond. I expect to send it to IANA and hopefully they'll publish that on the DHCPv4 options page. This list will primarily indicate the options that are in use, but I don't expect to give details of the data format, etc. That is what future I-Ds will hopefully do. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of peter_blatherwick@mitel.com Sent: Thursday, May 19, 2005 2:10 PM To: dhcwg@ietf.org; iana@iana.org Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 [ sorry, resend to add a subject for tracking... please ignore previous ] Hello DHC WG and IANA, Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned" list. Our usage is as follows. All are related to configuration of IP Phones (and similar devices) in a VoIP network. Option Usage ====== ===== 128 TFPT Server IP address (for IP Phone - specific sw load) 129 Call Server IP address 130 Discrimination string (to identify vendor) 131 Remote statistics server IP address 132 802.1P VLAN ID 133 802.1Q L2 Priority 134 Diffserv Code Point 135 HTTP Proxy for phone-specific applications Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are). Also, it is not completely clear whether an I-D documenting this same information is or is not required. We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods. Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options. Is an I-D required to complete the process of putting the options on the Tentatively Assigned list? While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state? Regards, Peter Blatherwick Sr. Solutions Architect, Mitel Networks --=_alternative 004D1D9485257007_= Content-Type: text/html; charset="us-ascii"
Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of that one, and believe there are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean.  However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04).   Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request.  

Is there a BCP or anything to give good advice on "best" approaches?  Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)

-- Peter




"Bernie Volz (volz)" <volz@cisco.com>

19.05.05 22:59

       
        To:        <peter_blatherwick@mitel.com>, <dhcwg@ietf.org>, <iana@iana.org>
        cc:        
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942



Thanks Peter.
 
I assume your usage of these option numbers has nothing to do with PXE.
 
Regarding the I-D, yes it would be useful to have that. But as there are conflicting uses of these option numbers, moving away from their use is highly recommended. So, it is up to you.
 
The I-D would be to document the existing usage.
 
If you make use of the RFC 3925 vendor options going forward, that would mean you would not need to standardize the new options via the IETF.
 
Yes, there will be a list. I am waiting until early June to compile that as I wanted to give people until the end of May to respond. I expect to send it to IANA and hopefully they'll publish that on the DHCPv4 options page.
 
This list will primarily indicate the options that are in use, but I don't expect to give details of the data format, etc. That is what future I-Ds will hopefully do.
 
- Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of peter_blatherwick@mitel.com
Sent: Thursday, May 19, 2005 2:10 PM
To: dhcwg@ietf.org; iana@iana.org
Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

[ sorry, resend to add a subject for tracking...  please ignore previous ]

Hello DHC WG and IANA,

Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP options 128-135 in the current vendor-specific range, and to request these be placed on the "Tentatively Assigned"  list.

Our usage is as follows.  All are related to configuration of IP Phones (and similar devices) in a VoIP network.

Option    Usage
======    =====
128       TFPT Server IP address (for IP Phone - specific sw load)
129       Call Server IP address
130       Discrimination string (to identify vendor)
131       Remote statistics server IP address
132       802.1P VLAN ID
133       802.1Q L2 Priority
134       Diffserv Code Point
135       HTTP Proxy for phone-specific applications


Please confirm that these will go on the Tentatively Assigned list (or perhaps some already are).

Also, it is not completely clear whether an I-D documenting this same information is or is not required.  We are currently looking at getting away from this scheme, in favor of better defined / standardized vendor-specific methods.  Given this, and the high likelihood of clashes over the same options wanted for use by others, we do not currently intend to pursue standardization of these options.  Is an I-D required to complete the process of putting the options on the Tentatively Assigned list?  

While we're on it, is there already, or will there be, a definitive list of all the options in Tentatively Assigned state?  

Regards,
Peter Blatherwick
Sr. Solutions Architect,
Mitel Networks

--=_alternative 004D1D9485257007_=-- --===============1794921678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1794921678==-- From dhcwg-bounces@ietf.org Fri May 20 10:16:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8J9-0004iK-7U; Fri, 20 May 2005 10:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8J5-0004iF-Vu for dhcwg@megatron.ietf.org; Fri, 20 May 2005 10:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20844 for ; Fri, 20 May 2005 10:16:53 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8aQ-00034e-5H for dhcwg@ietf.org; Fri, 20 May 2005 10:34:53 -0400 Received: from [206.172.52.116] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.34) id 1DZ8Il-0006Pi-D8; Fri, 20 May 2005 07:16:36 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 May 2005 07:16:05 -0700 Message-ID: From: "Kostur, Andre" To: "'peter_blatherwick@mitel.com'" , "Bernie Volz (volz)" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tenta tively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 07:15:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: -5.8 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: dhcwg@ietf.org, iana@iana.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857214149==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@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. --===============0857214149== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D46.70B82F60" 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_01C55D46.70B82F60 Content-Type: text/plain; charset="iso-8859-1" Re: Options 224+ Hold on... from the RFC: Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options. If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option! -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 7:05 AM To: Bernie Volz (volz) Thanks Bernie, Will generate the I-D. No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well. We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-) ------_=_NextPart_001_01C55D46.70B82F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP options 128-135 in use -- please place on = "Tentatively Assigned" list re. RFC 3942

Re: Options 224+

Hold on... from the RFC:

   Some vendors have made use of = site-specific option codes that violate
   the intent of the site-specific = options, as the options are used to
   configure features of their products = and thus are specific to many
   sites.  This usage could = potentially cause problems if a site that
   has been using the same site-specific = option codes for other purposes
   deploys products from one of the = vendors, or if two vendors pick the
   same site-specific options.


If you start using options 224+, you're just going to = end up in the same boat that we're in now.  Those options are for = site-specific options.  If your phones are going to be using those = options (and, BTW, we have some of these phones....) then it's no = longer a site-specific option!

-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mit= el.com]
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of = that one, and believe there are other conflicting usages as well. =

We have looked at RFC 3925 (options 124 / 125) of = course, and I certainly like it -- very clean.  However we do have = a strong concern that it may take some time before it becomes well = deployed, since it is still quite new (October 04).   Instead = (or possibly supplementally) we are looking at using options 60 / 43 to = exchange vendor info, or option 60 alone to identify the vendor with = retuned info in other options in the site range (224 and above) scoped = based on the vendor in the request.  

Is there a BCP or anything to give good advice on = "best" approaches?  Since there are no doubt about a = zillion other vendors in the same position, it would be good if we all = did at least roughly the same thing ;-)

------_=_NextPart_001_01C55D46.70B82F60-- --===============0857214149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0857214149==-- From dhcwg-bounces@ietf.org Fri May 20 10:29:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8Um-000753-QH; Fri, 20 May 2005 10:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8Uk-00074y-AQ for dhcwg@megatron.ietf.org; Fri, 20 May 2005 10:28:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22027 for ; Fri, 20 May 2005 10:28:56 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8m7-0003N3-Fm for dhcwg@ietf.org; Fri, 20 May 2005 10:46:56 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 10:28:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KESIeO015186; Fri, 20 May 2005 10:28:46 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 10:28:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 10:28:36 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3C93@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdRpyt7sw9YxicQvqHfSJANGsfKQAAJqqw From: "Bernie Volz \(volz\)" To: "Kostur, Andre" , X-OriginalArrivalTime: 20 May 2005 14:28:37.0960 (UTC) FILETIME=[36475480:01C55D48] X-Spam-Score: 0.6 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: dhcwg@ietf.org, iana@iana.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032751930==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1032751930== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D48.3622CE13" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D48.3622CE13 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yup, using the site specific option range is really a bad idea (whatever that range is). =20 You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.) =20 One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. =20 - Bernie ________________________________ From: Kostur, Andre [mailto:akostur@incognito.com]=20 Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 Re: Options 224+=20 Hold on... from the RFC:=20 Some vendors have made use of site-specific option codes that violate=20 the intent of the site-specific options, as the options are used to=20 configure features of their products and thus are specific to many=20 sites. This usage could potentially cause problems if a site that=20 has been using the same site-specific option codes for other purposes=20 deploys products from one of the vendors, or if two vendors pick the=20 same site-specific options.=20 If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option! -----Original Message-----=20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Friday, May 20, 2005 7:05 AM=20 To: Bernie Volz (volz)=20 Thanks Bernie,=20 Will generate the I-D. =20 No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well.=20 We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. =20 Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)=20 ------_=_NextPart_001_01C55D48.3622CE13 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP options 128-135 in use -- please = place on "Tentatively Assigned" list re. RFC 3942
Yup, using the site specific option range is = really a bad=20 idea (whatever that range is).
 
You can expect servers to start supporting RFC = 3925 ... and=20 the more people that want to start using this, the more likely the = server=20 vendors will start supporting it. Even if a server doesn't explicitly = support=20 it, most of them allow you to enter an arbitrary option number and data = to=20 return -- while having to construct the option data by hand is very = tricky, at=20 least it provides a means for supporting the option on older servers. = (Perhaps=20 it requires a tool where you configure the vendor specific data and it = spits out=20 some ASCII binary form that is usable to be cut and pasted into most = server's=20 configurations.)
 
One thing that isn't as clear as it could be in = RFC 3925 is=20 how a client communication interested in a certain vendor option set. = Part of=20 the reason for this is that it really is up to each vendor to determine = that.=20 But that does make it more difficult for server vendors to provide = appropriate=20 triggers. Likely most servers will require you to classify the incoming = request=20 in some way and then the options configured for that class are returned. = A=20 common trigger for this might be option = 60.
 
- Bernie

From: Kostur, Andre=20 [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 = 10:16=20 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz=20 (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: = RE:=20 [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively = Assigned"=20 list re. RFC 3942

Re: Options 224+

Hold on... from the RFC:

   Some vendors have made use of = site-specific=20 option codes that violate
   the = intent of=20 the site-specific options, as the options are used to
   configure features of their products and thus = are specific=20 to many
   sites.  This usage = could=20 potentially cause problems if a site that
  =20 has been using the same site-specific option codes for other = purposes=20
   deploys products from one of the = vendors, or if=20 two vendors pick the
   same = site-specific=20 options.


If you start using options 224+, you're just going = to end up=20 in the same boat that we're in now.  Those options are for = site-specific=20 options.  If your phones are going to be using those options = (and, BTW,=20 we have some of these phones....) then it's no longer a site-specific=20 option!

-----Original Message-----
From:=20 peter_blatherwick@mitel.com [mailto:peter_blatherwick@mite= l.com]=20
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of = that one,=20 and believe there are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of = course, and=20 I certainly like it -- very clean.  However we do have a strong = concern=20 that it may take some time before it becomes well deployed, since it = is still=20 quite new (October 04).   Instead (or possibly = supplementally) we=20 are looking at using options 60 / 43 to exchange vendor info, or = option 60=20 alone to identify the vendor with retuned info in other options in the = site=20 range (224 and above) scoped based on the vendor in the = request.  =20

Is there a BCP or anything to give good advice on = "best"=20 approaches?  Since there are no doubt about a zillion other = vendors in=20 the same position, it would be good if we all did at least roughly the = same=20 thing ;-)

------_=_NextPart_001_01C55D48.3622CE13-- --===============1032751930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1032751930==-- From dhcwg-bounces@ietf.org Fri May 20 11:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9dT-0007lh-0W; Fri, 20 May 2005 11:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9dQ-0007ka-Dh for dhcwg@megatron.ietf.org; Fri, 20 May 2005 11:42:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29703 for ; Fri, 20 May 2005 11:41:57 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ9un-0005Od-C6 for dhcwg@ietf.org; Fri, 20 May 2005 11:59:58 -0400 Received: from [206.172.52.116] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.34) id 1DZ9dB-0006bO-TR; Fri, 20 May 2005 08:41:46 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 May 2005 08:41:15 -0700 Message-ID: From: "Kostur, Andre" To: "'Bernie Volz (volz)'" , "Kostur, Andre" , peter_blatherwick@mitel.com Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tenta tively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 08:41:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: -5.8 (-----) X-Spam-Score: 0.9 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dhcwg@ietf.org, iana@iana.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704167509==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@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. --===============0704167509== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D52.5B123AF0" 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_01C55D52.5B123AF0 Content-Type: text/plain; charset="iso-8859-1" Isn't that the point of 124/125? The client sends in 124 with all of the vendor IDs it's interested in/supports, and a 3925 aware server would key off of that (instead of 60) to choose what to fill 125 with? -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, May 20, 2005 7:29 AM One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. ------_=_NextPart_001_01C55D52.5B123AF0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942
Isn't that the point of 124/125?  The client sends in 124 with all of the vendor IDs it's interested in/supports, and a 3925 aware server would key off of that (instead of 60) to choose what to fill 125 with?
-----Original Message-----
From: Bernie Volz (volz) [mailto:volz@cisco.com]
Sent: Friday, May 20, 2005 7:29 AM
 
One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.
 
------_=_NextPart_001_01C55D52.5B123AF0-- --===============0704167509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0704167509==-- From dhcwg-bounces@ietf.org Fri May 20 11:57:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9s9-0002Yo-H2; Fri, 20 May 2005 11:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9s7-0002Ye-SF for dhcwg@megatron.ietf.org; Fri, 20 May 2005 11:57:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01022 for ; Fri, 20 May 2005 11:57:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZA9W-0005m6-42 for dhcwg@ietf.org; Fri, 20 May 2005 12:15:10 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 12:07:51 -0400 X-IronPort-AV: i="3.93,123,1115006400"; d="scan'208,217"; a="50361715:sNHT1272558244" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KFuwnI004361; Fri, 20 May 2005 11:56:59 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 11:55:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 11:55:56 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3CD7@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdUn3Ug3hL3RSmRpeM2XBAqNWMZwAAWjDQ From: "Bernie Volz \(volz\)" To: "Kostur, Andre" , X-OriginalArrivalTime: 20 May 2005 15:55:58.0049 (UTC) FILETIME=[699D7510:01C55D54] X-Spam-Score: 0.9 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: dhcwg@ietf.org, iana@iana.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740674074==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1740674074== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D54.696BB35D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D54.696BB35D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ah, that's sort of what I thought, but it turns out that there isn't anything in the spec that says that. And, in speaking to Josh, there's valid reasons not to require this at all! A server might be configured to send these options always or for a certain "class" of clients (however that class is determined). =20 - Bernie ________________________________ From: Kostur, Andre [mailto:akostur@incognito.com]=20 Sent: Friday, May 20, 2005 11:41 AM To: Bernie Volz (volz); Kostur, Andre; peter_blatherwick@mitel.com Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 Isn't that the point of 124/125? The client sends in 124 with all of the vendor IDs it's interested in/supports, and a 3925 aware server would key off of that (instead of 60) to choose what to fill 125 with? -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, May 20, 2005 7:29 AM =09 =20 One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. =20 ------_=_NextPart_001_01C55D54.696BB35D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP options 128-135 in use -- please = place on "Tentatively Assigned" list re. RFC 3942
Ah, that's sort of what I thought, but it turns = out that=20 there isn't anything in the spec that says that. And, in speaking to = Josh,=20 there's valid reasons not to require this at all! A server might be = configured=20 to send these options always or for a certain "class" of clients = (however that=20 class is determined).
 
- Bernie

From: Kostur, Andre=20 [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 = 11:41=20 AM
To: Bernie Volz (volz); Kostur, Andre;=20 peter_blatherwick@mitel.com
Cc: dhcwg@ietf.org;=20 iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in = use --=20 please place on "Tentatively Assigned" list re. RFC = 3942

Isn't that the point of 124/125?  The = client=20 sends in 124 with all of the vendor IDs it's interested in/supports, = and a=20 3925 aware server would key off of that (instead of 60) to choose what = to fill=20 125 with?
-----Original Message-----
From: Bernie Volz = (volz)=20 [mailto:volz@cisco.com]
Sent: Friday, May 20, 2005 7:29=20 AM
 
One thing that isn't as clear as it could = be in RFC=20 3925 is how a client communication interested in a certain vendor = option=20 set. Part of the reason for this is that it really is up to each = vendor to=20 determine that. But that does make it more difficult for server = vendors to=20 provide appropriate triggers. Likely most servers will require you = to=20 classify the incoming request in some way and then the options = configured=20 for that class are returned. A common trigger for this might=20 be option 60.
 
------_=_NextPart_001_01C55D54.696BB35D-- --===============1740674074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1740674074==-- From dhcwg-bounces@ietf.org Fri May 20 12:38:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAWF-0005M2-46; Fri, 20 May 2005 12:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAWE-0005La-34 for dhcwg@megatron.ietf.org; Fri, 20 May 2005 12:38:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04930 for ; Fri, 20 May 2005 12:38:35 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAnc-0006yP-EL for dhcwg@ietf.org; Fri, 20 May 2005 12:56:37 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 8A61D200E7; Fri, 20 May 2005 12:38:28 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 26096-02; Fri, 20 May 2005 12:38:28 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 1C79E2009C; Fri, 20 May 2005 12:38:28 -0400 (EDT) To: "Bernie Volz (volz)" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Fri, 20 May 2005 12:40:51 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/20/2005 12:38:26 PM, Serialize complete at 05/20/2005 12:38:26 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.9 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0590135207==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============0590135207== Content-Type: multipart/alternative; boundary="=_alternative 005B67D685257007_=" This is a multipart message in MIME format. --=_alternative 005B67D685257007_= Content-Type: text/plain; charset="us-ascii" [I assume IANA does not need the noise, so removed from thread.] Thanks for the feedback. Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question. Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means. > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. -- Peter "Bernie Volz (volz)" 20.05.05 10:28 To: "Kostur, Andre" , cc: , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Yup, using the site specific option range is really a bad idea (whatever that range is). You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.) One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. - Bernie From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Re: Options 224+ Hold on... from the RFC: Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options. If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option! -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 7:05 AM To: Bernie Volz (volz) Thanks Bernie, Will generate the I-D. No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well. We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-) --=_alternative 005B67D685257007_= Content-Type: text/html; charset="us-ascii"
[I assume IANA does not need the noise, so removed from thread.]

Thanks for the feedback.  

Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info.  Interpretation is, for a given site, here are the options for this application.  Agree this is not preferred, just another thing we had looked at.  It appear you folks would be stronger than "not preferred".  

Any feedback on using option options 60 / 43?  It is a bit flawed for multiple vendors in the same exchange, I know.  But is it well supported in the field today is the real question.

Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap.  Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain.  But a pain we'd rather avoid or at least minimize.  Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.

   > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set.  
Hmmm, perhaps I need to re-read.  My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID.  Why would option 60 be used as a trigger at all.  

-- Peter




"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 10:28

       
        To:        "Kostur, Andre" <akostur@incognito.com>, <peter_blatherwick@mitel.com>
        cc:        <dhcwg@ietf.org>, <iana@iana.org>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942



Yup, using the site specific option range is really a bad idea (whatever that range is).
 
You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)
 
One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.
 
- Bernie

From: Kostur, Andre [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 10:16 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

Re: Options 224+

Hold on... from the RFC:

   Some vendors have made use of site-specific option codes that violate
  the intent of the site-specific options, as the options are used to
  configure features of their products and thus are specific to many
  sites.  This usage could potentially cause problems if a site that
  has been using the same site-specific option codes for other purposes
  deploys products from one of the vendors, or if two vendors pick the
  same site-specific options.

If you start using options 224+, you're just going to end up in the same boat that we're in now.  Those options are for site-specific options.  If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!

-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of that one, and believe there are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean.  However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04).   Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request.  

Is there a BCP or anything to give good advice on "best" approaches?  Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)

--=_alternative 005B67D685257007_=-- --===============0590135207== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0590135207==-- From dhcwg-bounces@ietf.org Fri May 20 12:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAZ1-000663-2f; Fri, 20 May 2005 12:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAYz-00065W-Sv for dhcwg@megatron.ietf.org; Fri, 20 May 2005 12:41:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05194 for ; Fri, 20 May 2005 12:41:27 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAqO-00074G-Bu for dhcwg@ietf.org; Fri, 20 May 2005 12:59:28 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id A3345200E2; Fri, 20 May 2005 12:41:20 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 26096-06; Fri, 20 May 2005 12:41:20 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 2D46920054; Fri, 20 May 2005 12:41:20 -0400 (EDT) To: "Bernie Volz (volz)" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Fri, 20 May 2005 12:43:44 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/20/2005 12:41:18 PM, Serialize complete at 05/20/2005 12:41:18 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.9 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: dhcwg@ietf.org, iana@iana.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0506572697==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============0506572697== Content-Type: multipart/alternative; boundary="=_alternative 005BABD585257007_=" This is a multipart message in MIME format. --=_alternative 005BABD585257007_= Content-Type: text/plain; charset="us-ascii" ... but if the returned data is keyed by vendor unique id, no matter how triggered, then it is up to the vendor app at the client to sort out how to interpret it. No? -- Peter "Bernie Volz (volz)" 20.05.05 11:55 To: "Kostur, Andre" , cc: , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Ah, that's sort of what I thought, but it turns out that there isn't anything in the spec that says that. And, in speaking to Josh, there's valid reasons not to require this at all! A server might be configured to send these options always or for a certain "class" of clients (however that class is determined). - Bernie From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Friday, May 20, 2005 11:41 AM To: Bernie Volz (volz); Kostur, Andre; peter_blatherwick@mitel.com Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Isn't that the point of 124/125? The client sends in 124 with all of the vendor IDs it's interested in/supports, and a 3925 aware server would key off of that (instead of 60) to choose what to fill 125 with? -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, May 20, 2005 7:29 AM One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. --=_alternative 005BABD585257007_= Content-Type: text/html; charset="us-ascii"
... but if the returned data is keyed by vendor unique id, no matter how triggered, then it is up to the vendor app at the client to sort out how to interpret it. No?  
-- Peter



"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 11:55

       
        To:        "Kostur, Andre" <akostur@incognito.com>, <peter_blatherwick@mitel.com>
        cc:        <dhcwg@ietf.org>, <iana@iana.org>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942



Ah, that's sort of what I thought, but it turns out that there isn't anything in the spec that says that. And, in speaking to Josh, there's valid reasons not to require this at all! A server might be configured to send these options always or for a certain "class" of clients (however that class is determined).
 
- Bernie

From: Kostur, Andre [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 11:41 AM
To: Bernie Volz (volz); Kostur, Andre; peter_blatherwick@mitel.com
Cc: dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942
Isn't that the point of 124/125?  The client sends in 124 with all of the vendor IDs it's interested in/supports, and a 3925 aware server would key off of that (instead of 60) to choose what to fill 125 with?
-----Original Message-----
From: Bernie Volz (volz) [mailto:volz@cisco.com]
Sent: Friday, May 20, 2005 7:29 AM
 
One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.
 

--=_alternative 005BABD585257007_=-- --===============0506572697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0506572697==-- From dhcwg-bounces@ietf.org Fri May 20 12:45:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAdA-0007kF-Im; Fri, 20 May 2005 12:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAd8-0007kA-K1 for dhcwg@megatron.ietf.org; Fri, 20 May 2005 12:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05477 for ; Fri, 20 May 2005 12:45:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAuW-0007BB-NH for dhcwg@ietf.org; Fri, 20 May 2005 13:03:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 12:45:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KGjYdw025927; Fri, 20 May 2005 12:45:34 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 12:45:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 12:45:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3CFF@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdWmtZcTS7ypHFQguI/Mr0JLiZgQAAHeag From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 20 May 2005 16:45:26.0917 (UTC) FILETIME=[5332C350:01C55D5B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0809687626==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0809687626== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D5B.53180C1D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D5B.53180C1D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Peter: =20 Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use. =20 I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it. =20 I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request. =20 - Bernie ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Friday, May 20, 2005 12:41 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 [I assume IANA does not need the noise, so removed from thread.] =09 Thanks for the feedback. =20 =09 Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". =20 =09 Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question.=20 =09 Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.=20 =09 > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. =20 Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. =20 =09 -- Peter=20 =09 =09 =09 =09 =09 "Bernie Volz (volz)" =20 20.05.05 10:28=20 =20 To: "Kostur, Andre" , =20 cc: , =20 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Yup, using the site specific option range is really a bad idea (whatever that range is).=20 =20 You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)=20 =20 One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.=20 =20 - Bernie=20 =09 =09 ________________________________ From: Kostur, Andre [mailto:akostur@incognito.com]=20 Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 Re: Options 224+=20 Hold on... from the RFC:=20 Some vendors have made use of site-specific option codes that violate=20 the intent of the site-specific options, as the options are used to=20 configure features of their products and thus are specific to many=20 sites. This usage could potentially cause problems if a site that=20 has been using the same site-specific option codes for other purposes=20 deploys products from one of the vendors, or if two vendors pick the=20 same site-specific options.=20 If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!=20 -----Original Message-----=20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com ]=20 Sent: Friday, May 20, 2005 7:05 AM=20 To: Bernie Volz (volz)=20 Thanks Bernie,=20 Will generate the I-D. =20 No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well.=20 We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. =20 Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)=20 =09 ------_=_NextPart_001_01C55D5B.53180C1D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) = use=20 site-specific options. They are not for vendor use.
 
I'm not saying that option 60 is the trigger = for 125, just=20 that it could be. As could any number of other things - such as the mac = address=20 or client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they = aren't=20 general purpose clients? If that is the case, using Option 60 is = certainly=20 possible and should not cause any issues since you're doing what that = option is=20 intended for - identifying the vendor of the client making the=20 request.
 
- Bernie

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, = 2005=20 12:41 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; = dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in = use --=20 please place on "Tentatively Assigned" list re. RFC = 3942


[I assume IANA does = not need the=20 noise, so removed from thread.]

Thanks for the feedback.  

Just to be clear, what we had discussed was to only pass back = options=20 in the site range based on having received option 60 containing the = vendor=20 info.  Interpretation is, for a given site, here are the options = for this=20 application.  Agree this is not preferred, just another thing we = had=20 looked at.  It appear you folks would be stronger than "not = preferred".=20  

Any feedback on = using=20 option options 60 / 43?  It is a bit flawed for multiple vendors = in the=20 same exchange, I know.  But is it well supported in the field = today is=20 the real question.

Issue with=20 using options 124/125 exchanges remains it is not out there very = widely now,=20 and deployment always takes time ... so we have a gap. =  Administrative=20 pain to construct the data, likely for several different flavors of = server, is=20 just that ... a pain.  But a pain we'd rather avoid or at least = minimize.=20  Forcing upgrades to the DHCP environment in the field is also a = pain,=20 and a cost that many will not be happy to suck up if there are other=20 means.

  =  > ...=20 One thing that isn't = as clear as it=20 could be in RFC 3925 is how a client communication interested in a = certain=20 vendor option set.  
Hmmm, perhaps I need to re-read.  My = understanding=20 was option 124 is used to pass a vendor unique ID (or several), along = with any=20 specific data (opaque to the DHCP process), and the server returns = info in 125=20 against the same vendor ID.  Why would option 60 be used as a = trigger at=20 all.  

-- = Peter=20




"Bernie Volz (volz)"=20 <volz@cisco.com>=20

20.05.05 10:28 =

        =
        To: =    =20    "Kostur, Andre" <akostur@incognito.com>,=20 <peter_blatherwick@mitel.com>
        cc:      =20  <dhcwg@ietf.org>, <iana@iana.org> =
        Subject: =  =20      RE: [dhcwg] DHCP options 128-135 in use -- = please=20 place on "Tentatively Assigned" list re. RFC=20 3942



Yup, using the site specific option range is really a bad = idea=20 (whatever that range is).
 
You can expect=20 servers to start supporting RFC 3925 ... and the more people that want = to=20 start using this, the more likely the server vendors will start = supporting it.=20 Even if a server doesn't explicitly support it, most of them allow you = to=20 enter an arbitrary option number and data to return -- while having to = construct the option data by hand is very tricky, at least it provides = a means=20 for supporting the option on older servers. (Perhaps it requires a = tool where=20 you configure the vendor specific data and it spits out some ASCII = binary form=20 that is usable to be cut and pasted into most server's = configurations.)=20
 
One thing that isn't as clear as it could be in = RFC 3925 is=20 how a client communication interested in a certain vendor option set. = Part of=20 the reason for this is that it really is up to each vendor to = determine that.=20 But that does make it more difficult for server vendors to provide = appropriate=20 triggers. Likely most servers will require you to classify the = incoming=20 request in some way and then the options configured for that class are = returned. A common trigger for this might be option 60. =
 
- Bernie

From: Kostur, Andre=20 [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 = 10:16=20 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz=20 (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: = RE:=20 [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively = Assigned"=20 list re. RFC 3942

Re: Options = 224+

Hold on... from the = RFC:

   Some vendors = have made use=20 of site-specific option codes that violate
  = the intent of=20 the site-specific options, as the options are used to
  configure features of their products and thus are = specific=20 to many
  sites.  This usage = could=20 potentially cause problems if a site that
  = has been using=20 the same site-specific option codes for other purposes
  deploys products from one of the vendors, or if = two vendors=20 pick the
  same site-specific=20 options.

If you start using options = 224+, you're=20 just going to end up in the same boat that we're in now.  Those = options=20 are for site-specific options.  If your phones are going to be = using=20 those options (and, BTW, we have some of these phones....) then it's = no longer=20 a site-specific option!=20

-----Original = Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20
Sent: Friday, May = 20, 2005 7:05=20 AM
To: Bernie Volz = (volz)

Thanks Bernie,

Will generate the I-D. =  

No, nothing to do with PXE. =  We=20 were aware of that one, and believe there are other conflicting usages = as=20 well.

We have looked at RFC 3925 = (options 124=20 / 125) of course, and I certainly like it -- very clean.  However = we do=20 have a strong concern that it may take some time before it becomes = well=20 deployed, since it is still quite new (October 04).   Instead (or = possibly supplementally) we are looking at using options 60 / 43 to = exchange=20 vendor info, or option 60 alone to identify the vendor with retuned = info in=20 other options in the site range (224 and above) scoped based on the = vendor in=20 the request.  

Is there a BCP or anything = to give good=20 advice on "best" approaches?  Since there are no doubt about a = zillion=20 other vendors in the same position, it would be good if we all did at = least=20 roughly the same thing ;-)

------_=_NextPart_001_01C55D5B.53180C1D-- --===============0809687626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0809687626==-- From dhcwg-bounces@ietf.org Fri May 20 12:48:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAfW-00088V-1E; Fri, 20 May 2005 12:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAfT-00088M-Sq for dhcwg@megatron.ietf.org; Fri, 20 May 2005 12:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05781 for ; Fri, 20 May 2005 12:48:08 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAws-0007Gx-2i for dhcwg@ietf.org; Fri, 20 May 2005 13:06:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 12:58:52 -0400 X-IronPort-AV: i="3.93,123,1115006400"; d="scan'208,217"; a="50370842:sNHT43936884" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KGlve0026635; Fri, 20 May 2005 12:48:00 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 12:47:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 12:47:55 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D02@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdWu3bSHb1AD9GS0OgIRrzsDdyvgAAHBow From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 20 May 2005 16:47:57.0196 (UTC) FILETIME=[ACC584C0:01C55D5B] X-Spam-Score: 1.1 (+) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0273553492==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0273553492== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D5B.ACB4D46F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D5B.ACB4D46F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Correct. =20 If you're IP phone is doing DHCP, then it would be up to it to intreprete this data. =20 If you're using Windows or Linux, it isn't necessarily clear how you would get this data though it is always possible that there is some place that these clients store "unknown" options and and you could get access to the data in your application. =20 - Bernie ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Friday, May 20, 2005 12:44 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 ... but if the returned data is keyed by vendor unique id, no matter how triggered, then it is up to the vendor app at the client to sort out how to interpret it. No? =20 -- Peter=20 =09 =09 =09 =09 "Bernie Volz (volz)" =20 20.05.05 11:55=20 =20 To: "Kostur, Andre" , =20 cc: , =20 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Ah, that's sort of what I thought, but it turns out that there isn't anything in the spec that says that. And, in speaking to Josh, there's valid reasons not to require this at all! A server might be configured to send these options always or for a certain "class" of clients (however that class is determined).=20 =20 - Bernie=20 =09 =09 ________________________________ From: Kostur, Andre [mailto:akostur@incognito.com]=20 Sent: Friday, May 20, 2005 11:41 AM To: Bernie Volz (volz); Kostur, Andre; peter_blatherwick@mitel.com Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 Isn't that the point of 124/125? The client sends in 124 with all of the vendor IDs it's interested in/supports, and a 3925 aware server would key off of that (instead of 60) to choose what to fill 125 with?=20 -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Friday, May 20, 2005 7:29 AM=20 =20 One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.=20 =20 =09 =09 ------_=_NextPart_001_01C55D5B.ACB4D46F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Correct.
 
If you're IP phone is doing DHCP, then it would = be up to it=20 to intreprete this data.
 
If you're using Windows or Linux, it isn't = necessarily=20 clear how you would get this data though it is always possible that = there is=20 some place that these clients store "unknown" options and and you could = get=20 access to the data in your application.
 
- Bernie

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, = 2005=20 12:44 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; = dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP = options=20 128-135 in use -- please place on "Tentatively Assigned" list re. RFC=20 3942


... but if the = returned data is=20 keyed by vendor unique id, no matter how triggered, then it is up to = the=20 vendor app at the client to sort out how to interpret it. No? =  =20
-- Peter



"Bernie Volz (volz)"=20 <volz@cisco.com>=20

20.05.05 11:55 =

        =
        To: =    =20    "Kostur, Andre" <akostur@incognito.com>,=20 <peter_blatherwick@mitel.com>
        cc:      =20  <dhcwg@ietf.org>, <iana@iana.org> =
        Subject: =  =20      RE: [dhcwg] DHCP options 128-135 in use -- = please=20 place on "Tentatively Assigned" list re. RFC=20 3942



Ah, that's sort of what I thought, but it turns out that = there isn't=20 anything in the spec that says that. And, in speaking to Josh, there's = valid=20 reasons not to require this at all! A server might be configured to = send these=20 options always or for a certain "class" of clients (however that class = is=20 determined).
 =20
- Bernie

From: Kostur, Andre=20 [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 = 11:41=20 AM
To: Bernie Volz (volz); Kostur, Andre;=20 peter_blatherwick@mitel.com
Cc: dhcwg@ietf.org;=20 iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in = use --=20 please place on "Tentatively Assigned" list re. RFC 3942

Isn't that the point of 124/125?  The client sends in = 124 with all=20 of the vendor IDs it's interested in/supports, and a 3925 aware server = would=20 key off of that (instead of 60) to choose what to fill 125 = with?=20
-----Original = Message-----
From: Bernie=20 Volz (volz) [mailto:volz@cisco.com]
Sent: Friday, May 20, = 2005 7:29=20 AM
  =
One thing that isn't as clear as it = could be in=20 RFC 3925 is how a client communication interested in a certain vendor = option=20 set. Part of the reason for this is that it really is up to each = vendor to=20 determine that. But that does make it more difficult for server = vendors to=20 provide appropriate triggers. Likely most servers will require you to = classify=20 the incoming request in some way and then the options configured for = that=20 class are returned. A common trigger for this might be option = 60.=20
 =20

------_=_NextPart_001_01C55D5B.ACB4D46F-- --===============0273553492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0273553492==-- From dhcwg-bounces@ietf.org Fri May 20 13:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAu4-0003Ru-8M; Fri, 20 May 2005 13:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAu3-0003Rk-7r for dhcwg@megatron.ietf.org; Fri, 20 May 2005 13:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08087 for ; Fri, 20 May 2005 13:03:12 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBBP-0007qV-Ed for dhcwg@ietf.org; Fri, 20 May 2005 13:21:14 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 50B9B20090; Fri, 20 May 2005 13:03:03 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 29434-02-4; Fri, 20 May 2005 13:03:02 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id D9A5920054; Fri, 20 May 2005 13:03:02 -0400 (EDT) To: "Bernie Volz (volz)" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Fri, 20 May 2005 13:05:26 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/20/2005 01:03:01 PM, Serialize complete at 05/20/2005 01:03:01 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.9 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1067541137==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1067541137== Content-Type: multipart/alternative; boundary="=_alternative 005DA84685257007_=" This is a multipart message in MIME format. --=_alternative 005DA84685257007_= Content-Type: text/plain; charset="us-ascii" So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT to return vendor-related info in site options range? We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand. Sorry to be picky about words, just trying to get it right. BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards. And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really. -- Peter "Bernie Volz (volz)" 20.05.05 12:45 To: cc: "Kostur, Andre" , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Peter: Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use. I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it. I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request. - Bernie From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 12:41 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 [I assume IANA does not need the noise, so removed from thread.] Thanks for the feedback. Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question. Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means. > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. -- Peter "Bernie Volz (volz)" 20.05.05 10:28 To: "Kostur, Andre" , cc: , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Yup, using the site specific option range is really a bad idea (whatever that range is). You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.) One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. - Bernie From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Re: Options 224+ Hold on... from the RFC: Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options. If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option! -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 7:05 AM To: Bernie Volz (volz) Thanks Bernie, Will generate the I-D. No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well. We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-) --=_alternative 005DA84685257007_= Content-Type: text/html; charset="us-ascii"
So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT  to return vendor-related info in site options range?  We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand.  

Sorry to be picky about words, just trying to get it right.

BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards.  And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really.

-- Peter




"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 12:45

       
        To:        <peter_blatherwick@mitel.com>
        cc:        "Kostur, Andre" <akostur@incognito.com>, <dhcwg@ietf.org>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942



Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use.
 
I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request.
 
- Bernie

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 12:41 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

[I assume IANA does not need the noise, so removed from thread.]

Thanks for the feedback.  

Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info.  Interpretation is, for a given site, here are the options for this application.  Agree this is not preferred, just another thing we had looked at.  It appear you folks would be stronger than "not preferred".  

Any feedback on using option options 60 / 43?  It is a bit flawed for multiple vendors in the same exchange, I know.  But is it well supported in the field today is the real question.

Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap.  Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain.  But a pain we'd rather avoid or at least minimize.  Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.

  > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set.  
Hmmm, perhaps I need to re-read.  My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID.  Why would option 60 be used as a trigger at all.  

-- Peter



"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 10:28

       
       To:        "Kostur, Andre" <akostur@incognito.com>, <peter_blatherwick@mitel.com>
       cc:        <dhcwg@ietf.org>, <iana@iana.org>
       Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942




Yup, using the site specific option range is really a bad idea (whatever that range is).
 
You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)
 
One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.
 
- Bernie

From: Kostur, Andre [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 10:16 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

Re: Options 224+

Hold on... from the RFC:

   Some vendors have made use of site-specific option codes that violate
 the intent of the site-specific options, as the options are used to
 configure features of their products and thus are specific to many
 sites.  This usage could potentially cause problems if a site that
 has been using the same site-specific option codes for other purposes
 deploys products from one of the vendors, or if two vendors pick the
 same site-specific options.

If you start using options 224+, you're just going to end up in the same boat that we're in now.  Those options are for site-specific options.  If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!

-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of that one, and believe there are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean.  However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04).   Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request.  

Is there a BCP or anything to give good advice on "best" approaches?  Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)

--=_alternative 005DA84685257007_=-- --===============1067541137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1067541137==-- From dhcwg-bounces@ietf.org Fri May 20 13:12:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZB2s-0006gN-K1; Fri, 20 May 2005 13:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZB2q-0006gD-LE for dhcwg@megatron.ietf.org; Fri, 20 May 2005 13:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09218 for ; Fri, 20 May 2005 13:12:17 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBKB-0008AY-MS for dhcwg@ietf.org; Fri, 20 May 2005 13:30:19 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 13:22:57 -0400 X-IronPort-AV: i="3.93,123,1115006400"; d="scan'208,217"; a="50374856:sNHT53686420" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KHBWnm024943; Fri, 20 May 2005 13:12:05 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 13:11:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 13:11:57 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D1A@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdXdr0Lc45DBOGR56k0hN2j12IiQAAOzKQ From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 20 May 2005 17:11:59.0147 (UTC) FILETIME=[083DC7B0:01C55D5F] X-Spam-Score: 0.8 (/) X-Scan-Signature: b656e85d4d33f5403d96bac6146425d9 Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0608019276==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0608019276== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D5F.0822E717" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D5F.0822E717 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Peter: =20 NEVER USE SITE-SPECIFIC OPTIONS! Period. =20 I'm talking about using option 125. =20 - Bernie ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Friday, May 20, 2005 1:05 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT to return vendor-related info in site options range? We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand. =20 =09 Sorry to be picky about words, just trying to get it right.=20 =09 BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards. And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really.=20 =09 -- Peter=20 =09 =09 =09 =09 =09 "Bernie Volz (volz)" =20 20.05.05 12:45=20 =20 To: =20 cc: "Kostur, Andre" , =20 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Peter:=20 =20 Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use.=20 =20 I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it.=20 =20 I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request.=20 =20 - Bernie=20 =09 =09 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Friday, May 20, 2005 12:41 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 [I assume IANA does not need the noise, so removed from thread.] =09 Thanks for the feedback. =20 =09 Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". =20 =09 Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question.=20 =09 Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.=20 =09 > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. =20 =09 -- Peter=20 =09 =09 =09 =09 "Bernie Volz (volz)" =20 20.05.05 10:28=20 =20 To: "Kostur, Andre" , =20 cc: , =20 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 =09 Yup, using the site specific option range is really a bad idea (whatever that range is).=20 =20 You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)=20 =20 One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.=20 =20 - Bernie=20 =09 =09 ________________________________ From: Kostur, Andre [mailto:akostur@incognito.com]=20 Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942=20 Re: Options 224+=20 Hold on... from the RFC:=20 Some vendors have made use of site-specific option codes that violate=20 the intent of the site-specific options, as the options are used to=20 configure features of their products and thus are specific to many=20 sites. This usage could potentially cause problems if a site that=20 has been using the same site-specific option codes for other purposes=20 deploys products from one of the vendors, or if two vendors pick the=20 same site-specific options.=20 If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!=20 -----Original Message-----=20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com ]=20 Sent: Friday, May 20, 2005 7:05 AM=20 To: Bernie Volz (volz)=20 Thanks Bernie,=20 Will generate the I-D. =20 No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well.=20 We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. =20 Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)=20 =09 ------_=_NextPart_001_01C55D5F.0822E717 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Peter:
 
NEVER USE SITE-SPECIFIC OPTIONS!=20 Period.
 
I'm talking about using option = 125.
 
- Bernie

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, = 2005=20 1:05 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre;=20 dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in = use --=20 please place on "Tentatively Assigned" list re. RFC = 3942


So, if we advertise = vendor in=20 option 60, and scope the response based on this, is it: a) acceptable, = b) a=20 Bad Idea, or c) MUST NOT  to return vendor-related info in site = options=20 range?  We had never proposed to just blindly use a different = site range=20 without scoping it and being able to occupy options as needed by the=20 particular site at hand.  

Sorry to be picky about words, just trying to get it right.=20

BTW, From my view at = least "IP=20 Phone" is a very slippery term indeed these days, and moving slowly in = the=20 direction of being general purpose in many regards.  And like = many VoIP=20 folks, we also configure other applications which look very much like = IP=20 Phones but are not really.

--=20 Peter




"Bernie Volz (volz)"=20 <volz@cisco.com>=20

20.05.05 12:45 =

        =
        To: =    =20    <peter_blatherwick@mitel.com> =
        cc: =    =20    "Kostur, Andre" <akostur@incognito.com>,=20 <dhcwg@ietf.org>
 =20       Subject:        RE: = [dhcwg]=20 DHCP options 128-135 in use -- please place on "Tentatively = Assigned"=20 list re. RFC 3942



Peter:
 
Yes, you MUST NOT=20 (per RFC 2119 terminology) use site-specific options. They are not for = vendor=20 use.
  =
I'm not saying that option 60 is = the trigger for=20 125, just that it could be. As could any number of other things - such = as the=20 mac address or client id, option 124 data, ... you name it. =
 
I assume your IP phones are just that ... they aren't general = purpose=20 clients? If that is the case, using Option 60 is certainly possible = and should=20 not cause any issues since you're doing what that option is intended = for -=20 identifying the vendor of the client making the request. =
 
- Bernie

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, = 2005=20 12:41 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; = dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in = use --=20 please place on "Tentatively Assigned" list re. RFC 3942


[I assume IANA does not need the noise, so removed from=20 thread.] =

Thanks for the feedback. =  

Just to be clear, what we had discussed was to only pass = back=20 options in the site range based on having received option 60 = containing the=20 vendor info.  Interpretation is, for a given site, here are the = options=20 for this application.  Agree this is not preferred, just another = thing we=20 had looked at.  It appear you folks would be stronger than "not=20 preferred".   =

Any feedback on using option options 60 = / 43?=20  It is a bit flawed for multiple vendors in the same exchange, I = know.=20  But is it well supported in the field today is the real=20 question. =

Issue with using options 124/125 = exchanges remains=20 it is not out there very widely now, and deployment always takes time = ... so=20 we have a gap.  Administrative pain to construct the data, likely = for=20 several different flavors of server, is just that ... a pain. =  But a pain=20 we'd rather avoid or at least minimize.  Forcing upgrades to the = DHCP=20 environment in the field is also a pain, and a cost that many will not = be=20 happy to suck up if there are other means.

  > = ...=20 One thing that isn't = as clear as it=20 could be in RFC 3925 is how a client communication interested in a = certain=20 vendor option set.  
Hmmm,=20 perhaps I need to re-read.  My understanding was option 124 is = used to=20 pass a vendor unique ID (or several), along with any specific data = (opaque to=20 the DHCP process), and the server returns info in 125 against the same = vendor=20 ID.  Why would option 60 be used as a trigger at all. =  

--=20 Peter =



"Bernie Volz = (volz)"=20 <volz@cisco.com>=20

20.05.05 10:28

      =  =20
      =  To:=20        "Kostur, Andre"=20 <akostur@incognito.com>,=20 <peter_blatherwick@mitel.com>
  =    =20  cc:        <dhcwg@ietf.org>,=20 <iana@iana.org>=20
      =  Subject:        RE: [dhcwg] DHCP = options=20 128-135 in use -- please place on "Tentatively Assigned" list = re. RFC=20 3942




Yup, using the=20 site specific option range is really a bad idea (whatever that range=20 is). =
 
You can expect servers to start = supporting=20 RFC 3925 ... and the more people that want to start using this, the = more=20 likely the server vendors will start supporting it. Even if a server = doesn't=20 explicitly support it, most of them allow you to enter an arbitrary = option=20 number and data to return -- while having to construct the option data = by hand=20 is very tricky, at least it provides a means for supporting the option = on=20 older servers. (Perhaps it requires a tool where you configure the = vendor=20 specific data and it spits out some ASCII binary form that is usable = to be cut=20 and pasted into most server's configurations.)
 
One thing that isn't as clear as it could be in RFC 3925 = is how a=20 client communication interested in a certain vendor option set. Part = of the=20 reason for this is that it really is up to each vendor to determine = that. But=20 that does make it more difficult for server vendors to provide = appropriate=20 triggers. Likely most servers will require you to classify the = incoming=20 request in some way and then the options configured for that class are = returned. A common trigger for this might be option 60.
 
- Bernie =

From: Kostur, Andre=20 [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 = 10:16=20 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz=20 (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: = RE:=20 [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively = Assigned"=20 list re. RFC 3942=20

Re: Options = 224+

Hold on... from the = RFC:

   Some vendors = have made use=20 of site-specific option codes that violate
 the = intent of the=20 site-specific options, as the options are used to
 configure features of their products and thus are = specific to=20 many
 sites.  This usage = could=20 potentially cause problems if a site that
 has = been using=20 the same site-specific option codes for other purposes
 deploys products from one of the vendors, or if two = vendors=20 pick the
 same site-specific=20 options.

If you start using options = 224+, you're=20 just going to end up in the same boat that we're in now.  Those = options=20 are for site-specific options.  If your phones are going to be = using=20 those options (and, BTW, we have some of these phones....) then it's = no longer=20 a site-specific option! =

-----Original = Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20
Sent: Friday, May = 20, 2005 7:05=20 AM
To: Bernie Volz = (volz)

Thanks Bernie,

Will generate the I-D. =  

No, nothing to do with PXE. =  We=20 were aware of that one, and believe there are other conflicting usages = as=20 well.

We have looked at RFC 3925 = (options 124=20 / 125) of course, and I certainly like it -- very clean.  However = we do=20 have a strong concern that it may take some time before it becomes = well=20 deployed, since it is still quite new (October 04).   Instead (or = possibly supplementally) we are looking at using options 60 / 43 to = exchange=20 vendor info, or option 60 alone to identify the vendor with retuned = info in=20 other options in the site range (224 and above) scoped based on the = vendor in=20 the request.  

Is there a BCP or anything = to give good=20 advice on "best" approaches?  Since there are no doubt about a = zillion=20 other vendors in the same position, it would be good if we all did at = least=20 roughly the same thing ;-)

------_=_NextPart_001_01C55D5F.0822E717-- --===============0608019276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0608019276==-- From dhcwg-bounces@ietf.org Fri May 20 13:14:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZB4w-0007ae-Kx; Fri, 20 May 2005 13:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZB4u-0007Zb-Q8 for dhcwg@megatron.ietf.org; Fri, 20 May 2005 13:14:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09613 for ; Fri, 20 May 2005 13:14:25 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBMG-0008Fg-Kq for dhcwg@ietf.org; Fri, 20 May 2005 13:32:27 -0400 Received: from [206.172.52.116] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.34) id 1DZB4Y-0006qd-OW; Fri, 20 May 2005 10:14:08 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 May 2005 10:13:36 -0700 Message-ID: From: "Kostur, Andre" To: "'peter_blatherwick@mitel.com'" , "Bernie Volz (volz)" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tenta tively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 10:13:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: -5.8 (-----) X-Spam-Score: 0.8 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242131912==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@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. --===============1242131912== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D5F.3E2B7980" 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_01C55D5F.3E2B7980 Content-Type: text/plain; charset="iso-8859-1" IMHO: As a _vendor_, you MUST NOT mandate that any site-specific options be sent back to your device. Theoretically speaking, as a site administrator I may wish to send option 230 back to every device that requests, because I may have some custom DHCP tracking monitoring software that's looking for someting in 230. Since this is a site-specific thing (it's completely localized to my site, and makes no sense in anybody else's site), I can use 230 without worrying about it conflicting with anything else. Now if I deploy a Mtel IP phone into this site (assuming Mitel has moved say the VLAN ID option to 130), I can no longer do that since a vendor has mandated a site-specific option to be sent back to a general-use device. Besides... in most of your deployments, aren't the phones doing DHCP against an ICP200 or MAS6000 box anyway (_both_ of which are until Mitel's control), so upgrading whatever DHCP service on those to be 3925 compliant shouldn't be too hard for Mitel... it's only sites like ours which are using a different DHCP service (ours) where 3925 compliance would be dependant on that DHCP service being compliant... -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 10:05 AM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT to return vendor-related info in site options range? We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand. Sorry to be picky about words, just trying to get it right. BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards. And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really. -- Peter "Bernie Volz (volz)" 20.05.05 12:45 To: cc: "Kostur, Andre" , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Peter: Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use. I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it. I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request. - Bernie _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 12:41 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 [I assume IANA does not need the noise, so removed from thread.] Thanks for the feedback. Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question. Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means. > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. -- Peter "Bernie Volz (volz)" 20.05.05 10:28 To: "Kostur, Andre" , cc: , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Yup, using the site specific option range is really a bad idea (whatever that range is). You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.) One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. - Bernie _____ From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Re: Options 224+ Hold on... from the RFC: Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options. If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option! -----Original Message----- From: peter_blatherwick@mitel.com [ mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 7:05 AM To: Bernie Volz (volz) Thanks Bernie, Will generate the I-D. No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well. We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-) ------_=_NextPart_001_01C55D5F.3E2B7980 Content-Type: text/html; charset="iso-8859-1"
IMHO:
 
As a _vendor_, you MUST NOT mandate that any site-specific options be sent back to your device.  Theoretically speaking, as a site administrator I may wish to send option 230 back to every device that requests, because I may have some custom DHCP tracking monitoring software that's looking for someting in 230.  Since this is a site-specific thing (it's completely localized to my site, and makes no sense in anybody else's site), I can use 230 without worrying about it conflicting with anything else.  Now if I deploy a Mtel IP phone into this site (assuming Mitel has moved say the VLAN ID option to 130), I can no longer do that since a vendor has mandated a site-specific option to be sent back to a general-use device.
 
Besides... in most of your deployments, aren't the phones doing DHCP against an ICP200 or MAS6000 box anyway (_both_ of which are until Mitel's control), so upgrading whatever DHCP service on those to be 3925 compliant shouldn't be too hard for Mitel... it's only sites like ours which are using a different DHCP service (ours) where 3925 compliance would be dependant on that DHCP service being compliant...
-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 10:05 AM
To: Bernie Volz (volz)
Cc: Kostur, Andre; dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942


So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT  to return vendor-related info in site options range?  We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand.  

Sorry to be picky about words, just trying to get it right.

BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards.  And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really.

-- Peter




"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 12:45

       
        To:        <peter_blatherwick@mitel.com>
        cc:        "Kostur, Andre" <akostur@incognito.com>, <dhcwg@ietf.org>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942



Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use.
 
I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request.
 
- Bernie

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 12:41 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942


[I assume IANA does not need the noise, so removed from thread.]

Thanks for the feedback.  

Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info.  Interpretation is, for a given site, here are the options for this application.  Agree this is not preferred, just another thing we had looked at.  It appear you folks would be stronger than "not preferred".  

Any feedback on using option options 60 / 43?  It is a bit flawed for multiple vendors in the same exchange, I know.  But is it well supported in the field today is the real question.

Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap.  Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain.  But a pain we'd rather avoid or at least minimize.  Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.

  > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set.  
Hmmm, perhaps I need to re-read.  My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID.  Why would option 60 be used as a trigger at all.  

-- Peter



"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 10:28

       
       To:        "Kostur, Andre" <akostur@incognito.com>, <peter_blatherwick@mitel.com>
       cc:        <dhcwg@ietf.org>, <iana@iana.org>
       Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942




Yup, using the site specific option range is really a bad idea (whatever that range is).
 
You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)
 
One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.
 
- Bernie

From: Kostur, Andre [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 10:16 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

Re: Options 224+

Hold on... from the RFC:

   Some vendors have made use of site-specific option codes that violate
 the intent of the site-specific options, as the options are used to
 configure features of their products and thus are specific to many
 sites.  This usage could potentially cause problems if a site that
 has been using the same site-specific option codes for other purposes
 deploys products from one of the vendors, or if two vendors pick the
 same site-specific options.

If you start using options 224+, you're just going to end up in the same boat that we're in now.  Those options are for site-specific options.  If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!

-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of that one, and believe there are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean.  However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04).   Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request.  

Is there a BCP or anything to give good advice on "best" approaches?  Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)

------_=_NextPart_001_01C55D5F.3E2B7980-- --===============1242131912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1242131912==-- From dhcwg-bounces@ietf.org Fri May 20 13:33:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBNC-0003zh-RY; Fri, 20 May 2005 13:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBNC-0003zX-2G for dhcwg@megatron.ietf.org; Fri, 20 May 2005 13:33:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11389 for ; Fri, 20 May 2005 13:33:18 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBeb-0000Jv-6c for dhcwg@ietf.org; Fri, 20 May 2005 13:51:21 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHXCoc017440 for ; Fri, 20 May 2005 13:33:12 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KHXCi4148628 for ; Fri, 20 May 2005 13:33:12 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KHXCBI024176 for ; Fri, 20 May 2005 13:33:12 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHXCM8024144 for ; Fri, 20 May 2005 13:33:12 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KHXBH2022274 for ; Fri, 20 May 2005 13:33:11 -0400 Message-Id: <200505201733.j4KHXBH2022274@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Fri, 20 May 2005 13:33:11 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [dhcwg] FWD: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Forgot to cc the dhc group on this. ------- Forwarded Message From: Thomas Narten To: ipv6@ietf.org Date: Fri, 20 May 2005 13:24:26 -0400 Subject: meta thoughts on m/o bits Stepping up a level (and this also reflects my thinking after a private exchange with Ralph/Bernie - but not necessarily their thinking!)... I think the M/O bits (in retrospect) have turned out to be more trouble than they are worth. Indeed, they seem to be mostly just confusing. Thus, maybe we should work towards removing them completely. In an ideal world, there would be exactly one way for a client to invoke DHC. That is, it would use the same message exchange to get "addresses" as it did for "non-address configuration". In such a world, there would be no need for the M/O bits, since the client would do the same thing if either one of them were set. Unfortunately, we are not quite there, since DHC actually has HCB & ICB message exchanges (using Ralph's terminology). Thus, there are scenarios where invoking ICB is preferable over HCB. (Aside note: here is another example where having two ways to do similar things, results in undesirable complexity). Currently, we sort of need the M/O bits so a client can know which variant of DHC to invoke. But, we now also allow for the possibility of "silly states", i.e., states that aren't supposed to happen, but can, e.g., through misconfiguration. Having the M bit set but no addresses available is one such example. Ralph has already indicated that with some small changes to the DHC spec, we might be able to fix the DHC issue so that there is one way to invoke DHC that does the right thing in all combinations of addresses and/or other configuration information being available via DHC. If we had that, we wouldn't need two RA bits anymore. At most, a single "there is stuff to obtain via DHC" bit would suffice. Indeed, one could go further and say "just always invoke DHC", and don't even bother with an RA bit saying DHC is available. That has the nice property of being simple to implement and you don't have silly states where the RA bit(s) are configured incorrectly, etc. The only advantage I can see right off to having at least 1 RA bit is to tell the client "there is no DHC server running, so don't even bother". This would be a performance optimization to allow one to avoid needing to invoke DHC and have it timeout -- before concluding that there are no DHC servers. Is this a significant optimization? Hard to say. What I would like to suggest: followup on the above proposed DHC changes and see if we can actually "fix" DHC to simplify what the client has to do to invoke it. And if that works, do away with one or both of the RA bits. Remember, simplicity is Good! Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 13:43:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBWq-0006xe-UG; Fri, 20 May 2005 13:43:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBWn-0006xS-Si for dhcwg@megatron.ietf.org; Fri, 20 May 2005 13:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15007 for ; Fri, 20 May 2005 13:43:16 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBoC-0000sr-9e for dhcwg@ietf.org; Fri, 20 May 2005 14:01:17 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id E4C3C20127; Fri, 20 May 2005 13:43:07 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 03377-01; Fri, 20 May 2005 13:43:07 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 71C612011E; Fri, 20 May 2005 13:43:07 -0400 (EDT) To: "Kostur, Andre" Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Fri, 20 May 2005 13:45:30 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/20/2005 01:43:05 PM, Serialize complete at 05/20/2005 01:43:05 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.9 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: dhcwg@ietf.org, "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1633704513==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1633704513== Content-Type: multipart/alternative; boundary="=_alternative 006153AD85257007_=" This is a multipart message in MIME format. --=_alternative 006153AD85257007_= Content-Type: text/plain; charset="us-ascii" Hi Andre, Point taken, and also as per Bernie's STRONG WORDS ;-) I'm trying not to focus on a particular vendor here (though obviously I do have interests in a particular one). As with many others, we do not want to be dependent even on our own DHCP server implementation. We are looking for a general-purpose solution ... because our customers are. Any feedback on 60 / 43? Well deployed? Well understood in the real world? -- Peter "Kostur, Andre" 20.05.05 13:13 To: "'peter_blatherwick@mitel.com'" , "Bernie Volz (volz)" cc: "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tenta tively Assigned" list re. RFC 3942 IMHO: As a _vendor_, you MUST NOT mandate that any site-specific options be sent back to your device. Theoretically speaking, as a site administrator I may wish to send option 230 back to every device that requests, because I may have some custom DHCP tracking monitoring software that's looking for someting in 230. Since this is a site-specific thing (it's completely localized to my site, and makes no sense in anybody else's site), I can use 230 without worrying about it conflicting with anything else. Now if I deploy a Mtel IP phone into this site (assuming Mitel has moved say the VLAN ID option to 130), I can no longer do that since a vendor has mandated a site-specific option to be sent back to a general-use device. Besides... in most of your deployments, aren't the phones doing DHCP against an ICP200 or MAS6000 box anyway (_both_ of which are until Mitel's control), so upgrading whatever DHCP service on those to be 3925 compliant shouldn't be too hard for Mitel... it's only sites like ours which are using a different DHCP service (ours) where 3925 compliance would be dependant on that DHCP service being compliant... -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 10:05 AM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT to return vendor-related info in site options range? We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand. Sorry to be picky about words, just trying to get it right. BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards. And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really. -- Peter "Bernie Volz (volz)" 20.05.05 12:45 To: cc: "Kostur, Andre" , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Peter: Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use. I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it. I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request. - Bernie From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 12:41 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 [I assume IANA does not need the noise, so removed from thread.] Thanks for the feedback. Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question. Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means. > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. -- Peter "Bernie Volz (volz)" 20.05.05 10:28 To: "Kostur, Andre" , cc: , Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Yup, using the site specific option range is really a bad idea (whatever that range is). You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.) One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60. - Bernie From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Re: Options 224+ Hold on... from the RFC: Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options. If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option! -----Original Message----- From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Friday, May 20, 2005 7:05 AM To: Bernie Volz (volz) Thanks Bernie, Will generate the I-D. No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well. We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean. However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04). Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request. Is there a BCP or anything to give good advice on "best" approaches? Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-) --=_alternative 006153AD85257007_= Content-Type: text/html; charset="us-ascii"
Hi Andre,

Point taken, and also as per Bernie's STRONG WORDS ;-)

I'm trying not to focus on a particular vendor here (though obviously I do have interests in a particular one).   As with many others, we do not want to be dependent even on our own DHCP server implementation.   We are looking for a general-purpose solution ... because our customers are.  

Any feedback on 60 / 43?  Well deployed?  Well understood in the real world?  

-- Peter




"Kostur, Andre" <akostur@incognito.com>

20.05.05 13:13

       
        To:        "'peter_blatherwick@mitel.com'" <peter_blatherwick@mitel.com>, "Bernie Volz (volz)" <volz@cisco.com>
        cc:        "Kostur, Andre" <akostur@incognito.com>, dhcwg@ietf.org
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tenta        tively Assigned" list re. RFC 3942



IMHO:
 
As a _vendor_, you MUST NOT mandate that any site-specific options be sent back to your device.  Theoretically speaking, as a site administrator I may wish to send option 230 back to every device that requests, because I may have some custom DHCP tracking monitoring software that's looking for someting in 230.  Since this is a site-specific thing (it's completely localized to my site, and makes no sense in anybody else's site), I can use 230 without worrying about it conflicting with anything else.  Now if I deploy a Mtel IP phone into this site (assuming Mitel has moved say the VLAN ID option to 130), I can no longer do that since a vendor has mandated a site-specific option to be sent back to a general-use device.
 
Besides... in most of your deployments, aren't the phones doing DHCP against an ICP200 or MAS6000 box anyway (_both_ of which are until Mitel's control), so upgrading whatever DHCP service on those to be 3925 compliant shouldn't be too hard for Mitel... it's only sites like ours which are using a different DHCP service (ours) where 3925 compliance would be dependant on that DHCP service being compliant...
-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 10:05 AM
To: Bernie Volz (volz)
Cc: Kostur, Andre; dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

So, if we advertise vendor in option 60, and scope the response based on this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT  to return vendor-related info in site options range?  We had never proposed to just blindly use a different site range without scoping it and being able to occupy options as needed by the particular site at hand.  

Sorry to be picky about words, just trying to get it right.

BTW, From my view at least "IP Phone" is a very slippery term indeed these days, and moving slowly in the direction of being general purpose in many regards.  And like many VoIP folks, we also configure other applications which look very much like IP Phones but are not really.

-- Peter



"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 12:45

       
       To:        <peter_blatherwick@mitel.com>
       cc:        "Kostur, Andre" <akostur@incognito.com>, <dhcwg@ietf.org>
       Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942




Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use.
 
I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request.
 
- Bernie

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 12:41 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942


[I assume IANA does not need the noise, so removed from thread.]

Thanks for the feedback.  

Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info.  Interpretation is, for a given site, here are the options for this application.  Agree this is not preferred, just another thing we had looked at.  It appear you folks would be stronger than "not preferred".  

Any feedback on using option options 60 / 43?  It is a bit flawed for multiple vendors in the same exchange, I know.  But is it well supported in the field today is the real question.

Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap.  Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain.  But a pain we'd rather avoid or at least minimize.  Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.

 > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set.  
Hmmm, perhaps I need to re-read.  My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID.  Why would option 60 be used as a trigger at all.  

-- Peter


"Bernie Volz (volz)" <volz@cisco.com>

20.05.05 10:28

       
      To:        "Kostur, Andre" <akostur@incognito.com>, <peter_blatherwick@mitel.com>
      cc:        <dhcwg@ietf.org>, <iana@iana.org>
      Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942





Yup, using the site specific option range is really a bad idea (whatever that range is).

You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)

One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.

- Bernie

From: Kostur, Andre [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 10:16 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

Re: Options 224+

Hold on... from the RFC:

   Some vendors have made use of site-specific option codes that violate
the intent of the site-specific options, as the options are used to
configure features of their products and thus are specific to many
sites.  This usage could potentially cause problems if a site that
has been using the same site-specific option codes for other purposes
deploys products from one of the vendors, or if two vendors pick the
same site-specific options.

If you start using options 224+, you're just going to end up in the same boat that we're in now.  Those options are for site-specific options.  If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!

-----Original Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

Thanks Bernie,

Will generate the I-D.  

No, nothing to do with PXE.  We were aware of that one, and believe there are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly like it -- very clean.  However we do have a strong concern that it may take some time before it becomes well deployed, since it is still quite new (October 04).   Instead (or possibly supplementally) we are looking at using options 60 / 43 to exchange vendor info, or option 60 alone to identify the vendor with retuned info in other options in the site range (224 and above) scoped based on the vendor in the request.  

Is there a BCP or anything to give good advice on "best" approaches?  Since there are no doubt about a zillion other vendors in the same position, it would be good if we all did at least roughly the same thing ;-)

--=_alternative 006153AD85257007_=-- --===============1633704513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1633704513==-- From dhcwg-bounces@ietf.org Fri May 20 13:47:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBb7-0007fv-Hz; Fri, 20 May 2005 13:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBb4-0007fH-JW; Fri, 20 May 2005 13:47:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15498; Fri, 20 May 2005 13:47:41 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBsT-00011j-OZ; Fri, 20 May 2005 14:05:42 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHlQNG021138; Fri, 20 May 2005 13:47:27 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KHlQi4153890; Fri, 20 May 2005 13:47:26 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KHlQ1x017046; Fri, 20 May 2005 13:47:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHlQtU017035; Fri, 20 May 2005 13:47:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KHlPAm022320; Fri, 20 May 2005 13:47:25 -0400 Message-Id: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: Message from jinmei@isl.rdc.toshiba.co.jp of "Fri, 20 May 2005 16:19:26 +0900." Date: Fri, 20 May 2005 13:47:25 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > One possible case would be a server host which manually configures > itself with an IPv6 address, but seeks to get default router addresses > via an RA and possibly other configuration information such as > recursive DNS server addresses via DHCPv6 (Information-request/Reply). > Such a host would receive (and use) RAs but not invoke DHCPv6 for > address allocation even if the M flag is set in the RAs. There is nothing wrong with the above case. But, I don't think we need our specs need to say anything about them either. There are always going to be lots of scenarios where a vendor may want to do things differently than implement _only_ what the spec says _explicitely_. Thus, I see no reason to go into a lot of detail in one our specs supporting this particular scenario or "allowing" it to be "part of the standard" so to speak. That is, vendors always implement additional knobs/whistles as they see fit. The IETF doesn't need to account for all of those. What we our specs do need to support is not disallowing behavior that it might make sense to allow for, and that doesn't negatively impact interoperability and such. The above should be perfectly consistent with our existing specs. Do you (or others) feel otherwise? I.e., is the above not allowed by our specs? > I personally also expect a host that does not implement address > allocation via DHCPv6 would have an implicit local policy that > "disables" the behavior (regardless of the value of the M flag). But > I admit the current mo-flags document does not clearly indicate that > even if my expectation is reasonable. I do not understand the concept of having a local policy that disables invoking a service that one has not implemented. If you don't implement it you don't implement it, and anywhere you might consider invoking the service, well, you obviously just don't. That is not a "local policy", that is just common sense. :-) It has never been the case that if something is not in an IETF spec, it is "disallowed" or "not compliant" with a spec. If we go down that road, one ends up having to overspecify everything to make sure even obvious things are allowed. What our specs _do_ need to do is be very clear on what we expect all implementations to do, in order to achieve interoberability (and to prevent damaging behavior, as in, e.g., being congestion unfriendly). > On the other hand, I'd also like to allow a client to use DHCPv6 > (either full 3315 or the 3736 subset) even if the corresponding M or O > flag is not set. I agree that this should be allowed. Indeed, I'd expect that to be the default behavior regardless of the M/O bits. It should be the default behavior of anyone that implements DHC. No where in our specs (AFAIK) is it claimed that you SHOULD/MUST NOT invoke DHC if the M/O bits are clear. Right? > In particular, I'd reserve the possibility for a > host to try the RFC3736 behavior even if the O flag is off, so that > the host can get configuration information even when the RA flags and > available DHCPv6 are inconsistent (due to misconfiguration of routers, > etc). Is there any wording in our specs that suggests a client is not allowed to invoke DHC if either of the M or O bit is off? If not, why do people feel that they are not allowed to invoke DHC? > "_really_" sounds subjective, and opinions may vary, but I personally > don't think "the above" is enough in practice. In my understanding, > many people have been confused about the relationship between the M/O > flags and the "stateful" configuration protocol (we now know the > protocol is DHCPv6). At least I, as an implementor, have been always > confused about these points. For example, > 1. whether the specification about the M flag indicates address > allocation via DHCPv6 is a mandatory feature to be implemented in > hosts. (this point may now be clear by the "IPv6 Node > Requirements" document and recent clarification of 2462bis) The RA bits should have no bearing in answering that question. They are advisory only. I think folk have already made it clear that DHC on clients is not "mandatory to implement as part of IPv6". If that is the question you really have, this document is the wrong way to ask/resolve it. Another way of looking at things. Does the fact that someone can send a node a TCP SYN packet require (in the MUST sense) that the client respond to that SYN? Likewise, if an RA says "DHC is available", that doesn't mandate that it invoke DHC either. (but the node SHOULD do so...) > 2. whether it's valid for a host to not invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is set. (see above) That is why I suggested "SHOULD invoke DHC". Makes it clear you should, but there are cases where you might not want to, so no, it is not mandatory to _invoke_ (mandatory to implement is covered in the previous question). > 3. whether it's valid for a host to do invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is not set. (see also above) should be, IMO. The bits do not mean "if 0, you MUST NOT use DHC ..." > 4. what should the host do if the M or O flag is reset from ON to OFF. > (while I pernsoally believe RFC2462 is pretty clear on this, many > people, including a DHCPv6 specialist, have still misunderstood > that.) On to off? nothing. Let DHC continue to be used. The DHC protocol will do what it normally does if a DHC server goes away... I.e., if you've gotten config information from DHC that still has a valide lifetime, you wouldn't throw that information away... > 5. what if the M flag is set but the host does not get any DHCPv6 > Advertise in the initial exchange? Is it okay to fall back to the > RFC3736 subset? Or is it even okay to run both full RFC3315 and > the RFC3736 subset concurrently from the beginning? Should be legal, but this is an unfortunate situation, since we're not trying getting into how to deal with misconfigurations... Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 14:33:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCJp-0004in-HB; Fri, 20 May 2005 14:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCJn-0004hr-Pi; Fri, 20 May 2005 14:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21163; Fri, 20 May 2005 14:33:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCb9-0002X0-7O; Fri, 20 May 2005 14:51:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:33:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIXVe6025132; Fri, 20 May 2005 14:33:39 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:33:19 -0400 Received: from 161.44.65.166 ([161.44.65.166]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 18:33:19 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 14:33:39 -0400 From: Ralph Droms To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> References: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 14:33:38 -0400 Message-Id: <1116614019.11164.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 18:33:19.0599 (UTC) FILETIME=[6537A7F0:01C55D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Subject: [dhcwg] Re: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Well...DHCPv6 doesn't have any better mechanism for announcing availability of a server than does DHCPv4 (which is to say "none"). There has not been an identified need to push an announcement of DHCP server availability out to clients. Section 14 of RFC 3315 specifies the retransmission behavior for DHCP clients. When that behavior is interpreted for Solicit messages in section 17.1.2, the result is that the DHCP client continues to retransmit Solicit messages at low frequency (once every 2 minutes) forever. Therefore, the client will eventually contact the DHCP service when a server becomes available. - Ralph On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > This proposal looks better and easy to understand. However, > > if we just rely on timeout for concluding the unavailabiliy of DHCP server, > > how does the client re-invoke DHCP if the DHCP server is available later in > > time? I think we need one bit to inform the clients about the > > availabilty of DHCP > > services in the network. > > I would assume that DHC has mechanisms for discovering when DHC > servers come on line. I.e., the client just sits quietly in background. > > Sure, an RA bit could also signal the availability of a new server, > but I would first like to be convinced that the existing default DHC > mechanism isn't good enough for handling this case (better not to have > multiple ways of acheiving the same result). > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 14:43:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCTC-0000UN-IP; Fri, 20 May 2005 14:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCTA-0000To-2B; Fri, 20 May 2005 14:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22827; Fri, 20 May 2005 14:43:34 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCkY-000300-Tm; Fri, 20 May 2005 15:01:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 14:54:16 -0400 X-IronPort-AV: i="3.93,124,1115006400"; d="scan'208"; a="50390264:sNHT28555176" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIgqnS021786; Fri, 20 May 2005 14:43:23 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:43:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Date: Fri, 20 May 2005 14:43:14 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D66@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVdZArLm8ty52NqT/yepFCA7+YSOAABjlYQ From: "Bernie Volz \(volz\)" To: "Thomas Narten" , "JINMEI Tatuya / ????" X-OriginalArrivalTime: 20 May 2005 18:43:16.0483 (UTC) FILETIME=[C8FCED30:01C55D6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Excellent points Thomas.=20 > > 5. what if the M flag is set but the host does not get any DHCPv6 > > Advertise in the initial exchange? Is it okay to fall=20 > back to the > > RFC3736 subset? Or is it even okay to run both full RFC3315 and > > the RFC3736 subset concurrently from the beginning? >=20 > Should be legal, but this is an unfortunate situation, since we're not > trying getting into how to deal with misconfigurations... >=20 Probably the correct behavior for a client is to fallback to 3736 but periodically try 3315. This is similar to what Microsoft clients have been doing for a long time ... If configured for DHCPv4, they'll attempt it for a while and if it fails, they autoconfigure an address. But, that doesn't mean they stop doing DHCPv4. In fact, the host continues to do so (albeit at a less aggressive rate). So, for a *full* featured DHCPv6 client, if it is told to run (either because of local policy or because M bit set), if SHOULD attempt stateful address configuration. After some number of attempts (perhaps only 1), it may attempt stateless (3736). If it gets stuff, great. However, in any case it should continue to send Solicit's periodically. Isn't it the case that for Stateless Autoconfiguration a host that never receives an RA for its RS will periodically send RSs? Though perhaps that's not correct because a router will periodically send RAs. Regardless of which way it works, the point is still the same ... There are periodic attempts to communicate and that should be no different for DHCPv6.=20 - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 14:45:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCVJ-0000qP-P6; Fri, 20 May 2005 14:45:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCVG-0000p2-Ek; Fri, 20 May 2005 14:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23152; Fri, 20 May 2005 14:45:44 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCmg-00034v-4W; Fri, 20 May 2005 15:03:46 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:45:37 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIjFnQ022408; Fri, 20 May 2005 14:45:34 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:45:17 -0400 Received: from 161.44.65.166 ([161.44.65.166]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 18:45:16 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 14:45:36 -0400 From: Ralph Droms To: dhcwg@ietf.org, ipv6@ietf.org In-Reply-To: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> References: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 14:45:36 -0400 Message-Id: <1116614736.11164.40.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 18:45:17.0028 (UTC) FILETIME=[10D6A240:01C55D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Subject: [dhcwg] Re: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Comments in line... On Fri, 2005-05-20 at 14:33 -0400, Thomas Narten wrote: > > > => I'm curious about this, does DHCP broadcast its existence to > > > clients that never used it when it comes up? Seems a bit strange > > > to do that. I don't even know how it could speak to a client unsolicited. > > > > > > Yes, I do not think there is any message that has currently been defined > > in DHCP, that the servers broadcast without client solicitation. > > There are generally two ways to discover the existance of a server: > > - broadcast its existance (e.g., via a DHC broadcast or RA "DHC > server present" bit) There is no "DHCP broadcast", and changing the RA bit requires touching all the relevant routers. > - have clients periodically poll the server RFC 3315 currently specifies that clients poll (one message every two minutes) forever. > Each has different tradeoffs in terms of timeliness of discovering the > server vs. load on the network, etc. > > Those assuming a broadcast mechanism is needed may be making the > assumption that if an admin turns on a DHC server, it is a > _requirement_ that all nodes start using DHC effectively > _immediately_. > > It is not at all clear to me that this is a requirement. Which is why a broadcast mechanism in either DHCPv4 or DHCPv6. The operating environments for the two protocols are somewhat different; in general, if there is no DHCP server for IPv4 clients, those clients are simply unable to use the network, while if there is no DHCP server for IPv6 clients, those clients may be able to use SLAAC addresses. Either way, broadcasting the existence of a DHCP server is likely of value only in a very few, if any, cases. > I.e., it might be just fine to have all clients learn of DHC within > say 1-2 hours (if not longer), in which case background polling is > just fine. > > Remember, I don't think we're necessarily talking about the case where > a DHC server goes down. We're presumably talking about the case where > no DHC servers exist (and haven't for a long time), but the admin > decides it's time to enable DHC going forward. > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 14:49:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCYc-0001mb-BZ; Fri, 20 May 2005 14:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCYb-0001mT-67; Fri, 20 May 2005 14:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23829; Fri, 20 May 2005 14:49:11 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCpz-0003Et-VR; Fri, 20 May 2005 15:07:13 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:bc95:2d64:c352:46ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 802B31521A; Sat, 21 May 2005 03:51:28 +0900 (JST) Date: Sat, 21 May 2005 03:50:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> References: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (cc'ing the dhcwg list) >>>>> On Fri, 20 May 2005 13:24:26 -0400, >>>>> Thomas Narten said: > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. As a meta thought, I cannot agree more. In fact, the points you showed are (almost) exactly what I wanted to make when we first discussed the M/O flags issue in the rfc2462bis work (but you seem to express the points much better than I did). We actually once considered this option, whereas we didn't see some of the relevant points we now know. See, for example, a very long thread a year ago: http://www1.ietf.org/mail-archive/web/ipv6/current/msg02285.html As you can see in the thread archive, there was a strong push-back against the idea of removing these flags (while some others supported the idea). Then we finally decided to not remove the flags after a heated discussion. So, I'm wondering whether we can now really convince those who opposed to the idea. One additional meta note: even if we now decide to remove the flags, it wouldn't affect rfc2462bis, since it does not mention the flags at all. However, the decision would require a non-trivial (while not so big) change to rfc2461bis, which contains these flags in the RA message format and a brief description of these flags. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 14:49:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCZD-000258-9a; Fri, 20 May 2005 14:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCZA-00024B-SQ; Fri, 20 May 2005 14:49:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24001; Fri, 20 May 2005 14:49:47 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCqZ-0003Hq-Nh; Fri, 20 May 2005 15:07:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:49:39 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KInMeA029182; Fri, 20 May 2005 14:49:36 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:49:21 -0400 Received: from 161.44.65.166 ([161.44.65.166]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 18:49:21 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 14:49:41 -0400 Subject: Re: [dhcwg] Re: meta thoughts on m/o bits From: Ralph Droms To: dhcwg@ietf.org, ipv6@ietf.org In-Reply-To: <1116614736.11164.40.camel@localhost.localdomain> References: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> <1116614736.11164.40.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 14:49:41 -0400 Message-Id: <1116614981.11164.42.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 18:49:21.0998 (UTC) FILETIME=[A2DA16E0:01C55D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Small goof in previous message: > > Those assuming a broadcast mechanism is needed may be making the > > assumption that if an admin turns on a DHC server, it is a > > _requirement_ that all nodes start using DHC effectively > > _immediately_. > > > > It is not at all clear to me that this is a requirement. > > Which is why a broadcast mechanism in either DHCPv4 or DHCPv6. The ^is not defined > operating environments for the two protocols are somewhat different; in > general, if there is no DHCP server for IPv4 clients, those clients are > simply unable to use the network, while if there is no DHCP server for > IPv6 clients, those clients may be able to use SLAAC addresses. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 14:52:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCc6-0003At-Ih; Fri, 20 May 2005 14:52:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCc4-00037g-49; Fri, 20 May 2005 14:52:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24407; Fri, 20 May 2005 14:52:46 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCtT-0003PC-LH; Fri, 20 May 2005 15:10:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:52:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIqFnW024378; Fri, 20 May 2005 14:52:35 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:52:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] FWD: meta thoughts on m/o bits Date: Fri, 20 May 2005 14:52:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D6A@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] FWD: meta thoughts on m/o bits Thread-Index: AcVdYkVa1uCJX/WFR+aXQsg546CRDAACfj4A From: "Bernie Volz \(volz\)" To: "Thomas Narten" , , X-OriginalArrivalTime: 20 May 2005 18:52:26.0195 (UTC) FILETIME=[10A45230:01C55D6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This has my full support ... I kind of like the idea of one bit to say "run-DHCP if you otherwise wouldn't" but would leave the meaning as simple as that. Those hosts that run DHCP always (because that is how they are 'configured'), would do so. Note that if this bit is set, it means run FULL 3315 if you're able to and 3736 if you're not. Of course, if there's no DHCP client ... The client won't run either. That way, networks were bandwidth is a expensive or primarily mandate NOT using DHCP (or just stateless DHCP), COULD do so. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Thomas Narten > Sent: Friday, May 20, 2005 1:33 PM > To: dhcwg@ietf.org > Subject: [dhcwg] FWD: meta thoughts on m/o bits >=20 > Forgot to cc the dhc group on this. >=20 > ------- Forwarded Message >=20 > From: Thomas Narten > To: ipv6@ietf.org > Date: Fri, 20 May 2005 13:24:26 -0400 > Subject: meta thoughts on m/o bits >=20 > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... >=20 > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. >=20 > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. >=20 > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. >=20 > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. >=20 > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. >=20 > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. >=20 > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. >=20 > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. >=20 > Remember, simplicity is Good! >=20 > Thomas >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 15:06:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCor-0008Ay-44; Fri, 20 May 2005 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCop-0008Am-O9; Fri, 20 May 2005 15:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26191; Fri, 20 May 2005 15:05:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZD6D-0003rE-IK; Fri, 20 May 2005 15:24:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 15:05:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KJ5VnW028313; Fri, 20 May 2005 15:05:46 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 15:05:43 -0400 Received: from 161.44.65.166 ([161.44.65.166]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2005 19:05:43 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 15:06:03 -0400 From: Ralph Droms To: "Soliman, Hesham" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 15:06:03 -0400 Message-Id: <1116615963.11164.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 19:05:43.0856 (UTC) FILETIME=[EC15BB00:01C55D6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org No one is suggesting DHCP is the "default address configuration mechanism". Let's *please* not go down that discussion path... More comments in line. On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > In some scenarios there is a danger in the following approach: > - hosts boots > - looks for DHCP server, doesn't find one > - Keeps looking every couple of minutes A client is free to use some other timeout (2 hours instead of 2 minutes?) if it chooses. See sections 5, 14 and 17.1.2 of RFC 3315. I imagine standards bodies for specific environments (3GPP2?) might well mandate different retransmit timeouts, for example, to conserve bandwidth or power. > This leads to inefficient use of power and network resources > in some wireless devices. A more efficient way to do things is > to indicate in the RA whether the host should even try to find > a DHCP server. I find the current description in 2461/2bis > sufficient, dynamic and provides enough granularity to allow > hosts to look for what they need (i.e. addresses or "other" config). Yes, a bit indicating whether to expect a DHCP service at all might be useful ... although I, as an implementor, might be tempted to try the DHCP service anyway in certain circumstances; suppose there are no advertised prefixes from which to assign SLAAC addresses? > As a side note, we must not force DHCP to be a default address > configuration mechanism in IPv6. Stateless address config actually > provides a very useful and timely way of configuring addresses > for mobile nodes. > > Hesham > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On > > Behalf Of > > Ralph Droms > > Sent: Friday, May 20, 2005 2:34 PM > > To: ipv6@ietf.org; dhcwg@ietf.org > > Subject: Re: meta thoughts on m/o bits > > > > > > Well...DHCPv6 doesn't have any better mechanism for announcing > > availability of a server than does DHCPv4 (which is to say "none"). > > There has not been an identified need to push an announcement of DHCP > > server availability out to clients. > > > > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > > clients. When that behavior is interpreted for Solicit messages in > > section 17.1.2, the result is that the DHCP client continues to > > retransmit Solicit messages at low frequency (once every 2 minutes) > > forever. Therefore, the client will eventually contact the > > DHCP service > > when a server becomes available. > > > > - Ralph > > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > This proposal looks better and easy to understand. However, > > > > if we just rely on timeout for concluding the > > unavailabiliy of DHCP server, > > > > how does the client re-invoke DHCP if the DHCP server is > > available later in > > > > time? I think we need one bit to inform the clients about the > > > > availabilty of DHCP > > > > services in the network. > > > > > > I would assume that DHC has mechanisms for discovering when DHC > > > servers come on line. I.e., the client just sits quietly > > in background. > > > > > > Sure, an RA bit could also signal the availability of a new server, > > > but I would first like to be convinced that the existing > > default DHC > > > mechanism isn't good enough for handling this case (better > > not to have > > > multiple ways of acheiving the same result). > > > > > > Thomas > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 15:07:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCq6-0008RQ-FT; Fri, 20 May 2005 15:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCq4-0008Qc-I4 for dhcwg@megatron.ietf.org; Fri, 20 May 2005 15:07:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26384 for ; Fri, 20 May 2005 15:07:14 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZD7T-0003tg-8T for dhcwg@ietf.org; Fri, 20 May 2005 15:25:16 -0400 Received: by rproxy.gmail.com with SMTP id a41so536874rng for ; Fri, 20 May 2005 12:07:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f/0TuTrHZ6CNk5jQhzlDJkwTy6vKd3ex9dRQUsTjR7VXygM5VZmSkllPt0U7UX39EjRS2xEsmK4NrOHYyY748GtL+ukbDDYghx4VSsZ+lP/ukBqPQcyFXJdH/I2/+AsNPqj8InHinAdicnKQad1CuHLEWmSfhKvQiDg2AkK4fOw= Received: by 10.38.9.14 with SMTP id 14mr830458rni; Fri, 20 May 2005 12:07:13 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Fri, 20 May 2005 12:07:13 -0700 (PDT) Message-ID: <10e14db205052012077ee1fe99@mail.gmail.com> Date: Sat, 21 May 2005 00:37:13 +0530 From: Syam Madanapalli To: ipv6@ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] Re: meta thoughts on m/o bits In-Reply-To: <1116614019.11164.34.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> <1116614019.11164.34.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 5/21/05, Ralph Droms wrote: > Well...DHCPv6 doesn't have any better mechanism for announcing > availability of a server than does DHCPv4 (which is to say "none"). > There has not been an identified need to push an announcement of DHCP > server availability out to clients. > > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > clients. When that behavior is interpreted for Solicit messages in > section 17.1.2, the result is that the DHCP client continues to > retransmit Solicit messages at low frequency (once every 2 minutes) > forever. Therefore, the client will eventually contact the DHCP service > when a server becomes available. This may not be efficient for wireless networks where power and bandwidth are crucial. > > - Ralph > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > This proposal looks better and easy to understand. However, > > > if we just rely on timeout for concluding the unavailabiliy of DHCP s= erver, > > > how does the client re-invoke DHCP if the DHCP server is available la= ter in > > > time? I think we need one bit to inform the clients about the > > > availabilty of DHCP > > > services in the network. > > > > I would assume that DHC has mechanisms for discovering when DHC > > servers come on line. I.e., the client just sits quietly in background. > > > > Sure, an RA bit could also signal the availability of a new server, > > but I would first like to be convinced that the existing default DHC > > mechanism isn't good enough for handling this case (better not to have > > multiple ways of acheiving the same result). > > > > Thomas > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > _______________________________________________ > 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-bounces@ietf.org Fri May 20 15:26:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZD8n-0006NV-D2; Fri, 20 May 2005 15:26:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZD8l-0006Mt-Gq; Fri, 20 May 2005 15:26:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29446; Fri, 20 May 2005 15:26:33 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDQA-0004YK-9Y; Fri, 20 May 2005 15:44:35 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 15:37:14 -0400 X-IronPort-AV: i="3.93,124,1115006400"; d="scan'208"; a="50398108:sNHT33679436" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KJPbns003985; Fri, 20 May 2005 15:26:20 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 15:26:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2005 15:26:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D87@xmb-rtp-20a.amer.cisco.com> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdbssH2+mYkiCqTVyvr9/puMHYcwAAPLbwAABbcEA= From: "Bernie Volz \(volz\)" To: "Soliman, Hesham" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 20 May 2005 19:26:17.0184 (UTC) FILETIME=[CB34A600:01C55D71] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hesham: > =3D> You can try, but my concern is about how often you're going to = try. > If there are bits that say whether you should try or not and those=20 > bits are not set (i.e. no DHCP server in the network), why=20 > would you try? =20 This means that the wiresless operators will get more revenue from Ralph! If the wireless operator isn't using DHCP (or only using stateless), there's no reason they can't charge for that (stateful) traffic. This is the reason why having one (or two) bits in the RA to indicate whether DHCP should be run are useful. But, those bits are advisory only. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Soliman, Hesham > Sent: Friday, May 20, 2005 3:15 PM > To: Ralph Droms (rdroms) > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: meta thoughts on m/o bits >=20 >=20 >=20 > > No one is suggesting DHCP is the "default address configuration > > mechanism". Let's *please* not go down that discussion path... >=20 > =3D> some parts of the discussion were hinting at that, that's=20 > why I said "side note". I'm glad you're not suggesting that. >=20 > >=20 > > More comments in line. > >=20 > > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > > > In some scenarios there is a danger in the following approach: > > > - hosts boots > > > - looks for DHCP server, doesn't find one > > > - Keeps looking every couple of minutes > >=20 > > A client is free to use some other timeout (2 hours instead of 2 > > minutes?) if it chooses. See sections 5, 14 and 17.1.2 of=20 > > RFC 3315. I > > imagine standards bodies for specific environments (3GPP2?)=20 > > might well > > mandate different retransmit timeouts, for example, to conserve > > bandwidth or power. >=20 > =3D> It's unrealistic to assume that. An SDO might suggest that but > how does an implementation know it's in a 3GPP/2 or some other=20 > wireless network, or even ethernet? An implementation might just=20 > see a PPP driver or an ethernet driver. That says nothing about=20 > the underlying technology. >=20 > >=20 > > > This leads to inefficient use of power and network resources=20 > > > in some wireless devices. A more efficient way to do things is=20 > > > to indicate in the RA whether the host should even try to find > > > a DHCP server. I find the current description in 2461/2bis > > > sufficient, dynamic and provides enough granularity to allow > > > hosts to look for what they need (i.e. addresses or=20 > > "other" config). > >=20 > > Yes, a bit indicating whether to expect a DHCP service at=20 > > all might be > > useful ... although I, as an implementor, might be tempted=20 > to try the > > DHCP service anyway in certain circumstances; suppose there are no > > advertised prefixes from which to assign SLAAC addresses? >=20 > =3D> You can try, but my concern is about how often you're going to = try. > If there are bits that say whether you should try or not and those=20 > bits are not set (i.e. no DHCP server in the network), why=20 > would you try? >=20 > Hesham >=20 > >=20 > > > As a side note, we must not force DHCP to be a default address=20 > > > configuration mechanism in IPv6. Stateless address=20 > config actually > > > provides a very useful and timely way of configuring addresses=20 > > > for mobile nodes. > > >=20 > > > Hesham > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > > > > Behalf Of > > > > Ralph Droms > > > > Sent: Friday, May 20, 2005 2:34 PM > > > > To: ipv6@ietf.org; dhcwg@ietf.org > > > > Subject: Re: meta thoughts on m/o bits > > > >=20 > > > >=20 > > > > Well...DHCPv6 doesn't have any better mechanism for announcing > > > > availability of a server than does DHCPv4 (which is to=20 > > say "none"). > > > > There has not been an identified need to push an=20 > > announcement of DHCP > > > > server availability out to clients. > > > >=20 > > > > Section 14 of RFC 3315 specifies the retransmission=20 > > behavior for DHCP > > > > clients. When that behavior is interpreted for Solicit=20 > > messages in > > > > section 17.1.2, the result is that the DHCP client=20 > continues to > > > > retransmit Solicit messages at low frequency (once=20 > > every 2 minutes) > > > > forever. Therefore, the client will eventually contact the=20 > > > > DHCP service > > > > when a server becomes available. > > > >=20 > > > > - Ralph > > > >=20 > > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > > > This proposal looks better and easy to=20 > understand. However, > > > > > > if we just rely on timeout for concluding the=20 > > > > unavailabiliy of DHCP server, > > > > > > how does the client re-invoke DHCP if the DHCP server is=20 > > > > available later in=20 > > > > > > time? I think we need one bit to inform the clients=20 > > about the > > > > > > availabilty of DHCP > > > > > > services in the network. > > > > >=20 > > > > > I would assume that DHC has mechanisms for=20 > > discovering when DHC > > > > > servers come on line. I.e., the client just sits quietly=20 > > > > in background. > > > > >=20 > > > > > Sure, an RA bit could also signal the availability of=20 > > a new server, > > > > > but I would first like to be convinced that the existing=20 > > > > default DHC > > > > > mechanism isn't good enough for handling this case (better=20 > > > > not to have > > > > > multiple ways of acheiving the same result). > > > > >=20 > > > > > Thomas > > > > >=20 > > > > >=20 > > > >=20 > >=20 > -------------------------------------------------------------------- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests:=20 > > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > >=20 > >=20 > -------------------------------------------------------------------- > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 > https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged material=20 > for the sole use > > of the intended recipient. Any review or distribution by=20 > others is strictly > > prohibited. If you are not the intended recipient please=20 > contact the sender > > and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 15:31:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDDE-0006qa-Lh; Fri, 20 May 2005 15:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDDB-0006pa-TA; Fri, 20 May 2005 15:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29812; Fri, 20 May 2005 15:31:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDUa-0004f0-BL; Fri, 20 May 2005 15:49:10 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:bc95:2d64:c352:46ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5403A1521D; Sat, 21 May 2005 04:33:22 +0900 (JST) Date: Sat, 21 May 2005 04:31:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-Reply-To: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 20 May 2005 13:47:25 -0400, >>>>> Thomas Narten said: > That is, vendors always implement additional knobs/whistles as they > see fit. The IETF doesn't need to account for all of those. > What we our specs do need to support is not disallowing behavior that > it might make sense to allow for, and that doesn't negatively impact > interoperability and such. > The above should be perfectly consistent with our existing specs. Do > you (or others) feel otherwise? I.e., is the above not allowed by our > specs? (Perhaps it's not wise to continue this thread while we are in the separate "meta" thread, but) I believe we've basically agreed on each technical point (e.g., whether a host can perform DHCPv6 based on its decision/policy even if the corresponding M/O flag is off; the answer is "it can"). The real point in this thread is, at least to me, as follows: It's the fact that people have actually been confused about these points. We now know the answers to the questions, but I'm quite sure new implementors will ask the same questions in the future, since most of the background rationale is implicit, e.g., "this is valid since no specification explicitly prohibits it", and we'll continue answering the questions by saying "yes, it's valid because no specification explicitly prohibits it". I don't know if such confusion is just usual in the IETF specifications or there is something special for the M/O flags and DHCPv6 case, due to, for example, partly overwrapping functionality of "Host Configuration Behavior (full RFC3315)" and "Configuration Information Behavior (RFC3736 subset)" or other complexity you mentioned in the other thread. I personally think this is the latter case, and it makes sense to clarify these points explicitly in order to help future implementors (and ourselves by avoiding seeing/answering the same questions again and again). If I don't misunderstand him, Ralph also seems to think some clarification is useful. On the other hand, you and some other guys seem to regard this as a usual case which does not require explicit clarification. If this group is the majority, I won't fight against it; at least I now know the answers to the questions, so (hopefully) I won't be confused any more:-) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 16:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDgy-0000l1-Aj; Fri, 20 May 2005 16:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXrNG-0001Hi-EW; Mon, 16 May 2005 21:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27324; Mon, 16 May 2005 21:59:56 -0400 (EDT) Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXrdq-0002v8-Ur; Mon, 16 May 2005 22:17:11 -0400 Received: from S018431 ([141.154.125.12]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGM00DL42VR16Y2@vms042.mailsrvcs.net>; Mon, 16 May 2005 20:59:52 -0500 (CDT) Date: Mon, 16 May 2005 21:59:49 -0400 From: "timothy enos" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-reply-to: <8E296595B6471A4689555D5D725EBB212B3553@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz \(volz\)'" , "'Pekka Savola'" Message-id: <001401c55a84$1c246fa0$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 May 2005 16:01:53 -0400 Cc: dhcwg@ietf.org, 'IPv6 WG' , "'Ralph Droms \(rdroms\)'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie, Your points are well taken, and I agree. Making these flags 'hints' makes sense. Also, it seems that if a client does not know what to do (forgive the anthropomorphism) in response to having received an RA with the M (and O) bit(s) set (because it is not a DHCPv6 client), it would just ignore it/them. Also wondering if there are any RFC 3315-capable clients that, after failing to get config info from a DHCPv6 server 'x' times, would revert to SLAC? Tim Enos 1Sam16:7 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, May 16, 2005 5:20 PM To: Pekka Savola Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Hey, if they don't know what they're doing then set the bits and be done with it. If there's no DHCP server, the clients will try to get configuration information and fail and continuously try in the background. That's the safest fallback and the recommended default, IMHO. If they do set them wrong, it won't take long for users to complain. Just as they do now if the DHCP server or routing infrastructure is down. Trying to design for stupidity only produces the same. - Bernie > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, May 16, 2005 5:09 PM > To: Bernie Volz (volz) > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph > Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > BTW, if you want to look at this from the router administrator's > > perspective: > > > > Configure the router to send the M flag set in routing > advertisements > > for a Link IF: > > 1. A stateful DHCP server is deployed for that link (either on it or > > reachable via a relay agent) AND > > IMHO, you're making a significant leap of faith in assuming that > whoever configures the router's M-flag advertisements has sufficient > clue to grasp the different semantics that arise with: > > - M-flag and/or O-flag > - stateless and stateful clients > - stateless and stateful servers > - stateless and stateful relay agents > > Hence, if we want to build a robust system, we need to design it with > care. > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 16:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDgy-0000m2-TS; Fri, 20 May 2005 16:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYBrI-0004r4-C9; Tue, 17 May 2005 19:52:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04330; Tue, 17 May 2005 19:52:16 -0400 (EDT) Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYC87-0003Kc-Pv; Tue, 17 May 2005 20:09:45 -0400 Received: from S018431 ([141.154.125.12]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGN0051ERN2QBX5@vms044.mailsrvcs.net>; Tue, 17 May 2005 18:52:16 -0500 (CDT) Date: Tue, 17 May 2005 19:52:12 -0400 From: "timothy enos" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt In-reply-to: <8E296595B6471A4689555D5D725EBB212B370E@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz \(volz\)'" , "'Pekka Savola'" Message-id: <001a01c55b3b$72ac9c00$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 2.1 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 May 2005 16:01:53 -0400 Cc: dhcwg@ietf.org, 'IPv6 WG' , "'Ralph Droms \(rdroms\)'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Bernie, I'm well aware that stateful (DHCPv6, RFC 3315) and SLAC (RFC 2462) are independent of one another; not sure what in my question was unclear. While not required, I do appreciate the explanation. However my question is answered in RFC 3315, page 33 (section 17.1.2) quoted below: "A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link." My question was whether or not there are any existing implementations wherein a DHCPv6 client, after its MRC (being a positive integer) is reached, will then (as a backup or alternate method) seek to use SLAC. If so, they would clearly be in violation of the MUST as quoted above. The original question in this thread seemed to be about the M and O flags. I'd reaffirm that I agree with your contention on 16May05, 10:04am, quoted below: "In IPv6, the M and O flag should serve as hints. Period. A host is perfectly free to do what it wants (or what it has been configured to do)." Best regards, Tim 1Sam16:7 -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, May 17, 2005 3:41 PM To: timothy enos; Pekka Savola Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Tim: I'm not sure what you mean by your question ... SLAC (stateless auto-configuration) is independent of stateful. There may be some prefixes on a link that are stateful (0 or more) and others that are stateless (0 or more - excluding the link-local which is always stateless). So, SLAC is independent of stateful (DHCPv6). - Bernie > -----Original Message----- > From: timothy enos [mailto:timbeck04@verizon.net] > Sent: Monday, May 16, 2005 10:00 PM > To: Bernie Volz (volz); 'Pekka Savola' > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI > Tatuya / ????' > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > Bernie, > > Your points are well taken, and I agree. Making these flags 'hints' > makes sense. Also, it seems that if a client does not know what to do > (forgive the anthropomorphism) in response to having received > an RA with > the M (and O) bit(s) set (because it is not a DHCPv6 client), it would > just ignore it/them. > > Also wondering if there are any RFC 3315-capable clients that, after > failing to get config info from a DHCPv6 server 'x' times, > would revert > to SLAC? > > Tim Enos > 1Sam16:7 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 16:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDgz-0000mR-A8; Fri, 20 May 2005 16:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCan-0002db-6j; Fri, 20 May 2005 14:51:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24228; Fri, 20 May 2005 14:51:27 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCsC-0003LC-01; Fri, 20 May 2005 15:09:29 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 14:51:17 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2005 14:50:15 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdatgOTN4uDSjQSKydhtn70c2XFAAAVovw From: "Soliman, Hesham" To: "Ralph Droms" , , X-OriginalArrivalTime: 20 May 2005 18:51:17.0712 (UTC) FILETIME=[E7D2A500:01C55D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 May 2005 16:01:53 -0400 Cc: Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org In some scenarios there is a danger in the following approach: - hosts boots - looks for DHCP server, doesn't find one - Keeps looking every couple of minutes This leads to inefficient use of power and network resources=20 in some wireless devices. A more efficient way to do things is=20 to indicate in the RA whether the host should even try to find a DHCP server. I find the current description in 2461/2bis sufficient, dynamic and provides enough granularity to allow hosts to look for what they need (i.e. addresses or "other" config).=20 As a side note, we must not force DHCP to be a default address=20 configuration mechanism in IPv6. Stateless address config actually provides a very useful and timely way of configuring addresses=20 for mobile nodes. Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Ralph Droms > Sent: Friday, May 20, 2005 2:34 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Subject: Re: meta thoughts on m/o bits >=20 >=20 > Well...DHCPv6 doesn't have any better mechanism for announcing > availability of a server than does DHCPv4 (which is to say "none"). > There has not been an identified need to push an announcement of DHCP > server availability out to clients. >=20 > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > clients. When that behavior is interpreted for Solicit messages in > section 17.1.2, the result is that the DHCP client continues to > retransmit Solicit messages at low frequency (once every 2 minutes) > forever. Therefore, the client will eventually contact the=20 > DHCP service > when a server becomes available. >=20 > - Ralph >=20 > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > This proposal looks better and easy to understand. However, > > > if we just rely on timeout for concluding the=20 > unavailabiliy of DHCP server, > > > how does the client re-invoke DHCP if the DHCP server is=20 > available later in=20 > > > time? I think we need one bit to inform the clients about the > > > availabilty of DHCP > > > services in the network. > >=20 > > I would assume that DHC has mechanisms for discovering when DHC > > servers come on line. I.e., the client just sits quietly=20 > in background. > >=20 > > Sure, an RA bit could also signal the availability of a new server, > > but I would first like to be convinced that the existing=20 > default DHC > > mechanism isn't good enough for handling this case (better=20 > not to have > > multiple ways of acheiving the same result). > >=20 > > Thomas > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 16:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDgz-0000mt-PH; Fri, 20 May 2005 16:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCye-0002lt-1y; Fri, 20 May 2005 15:16:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28176; Fri, 20 May 2005 15:16:06 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDG4-0004Gc-3w; Fri, 20 May 2005 15:34:08 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 15:15:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2005 15:14:56 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdbssH2+mYkiCqTVyvr9/puMHYcwAAPLbw From: "Soliman, Hesham" To: "Ralph Droms" X-OriginalArrivalTime: 20 May 2005 19:15:58.0639 (UTC) FILETIME=[5A862BF0:01C55D70] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 May 2005 16:01:53 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > No one is suggesting DHCP is the "default address configuration > mechanism". Let's *please* not go down that discussion path... =3D> some parts of the discussion were hinting at that, that's=20 why I said "side note". I'm glad you're not suggesting that. >=20 > More comments in line. >=20 > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > > In some scenarios there is a danger in the following approach: > > - hosts boots > > - looks for DHCP server, doesn't find one > > - Keeps looking every couple of minutes >=20 > A client is free to use some other timeout (2 hours instead of 2 > minutes?) if it chooses. See sections 5, 14 and 17.1.2 of=20 > RFC 3315. I > imagine standards bodies for specific environments (3GPP2?)=20 > might well > mandate different retransmit timeouts, for example, to conserve > bandwidth or power. =3D> It's unrealistic to assume that. An SDO might suggest that but how does an implementation know it's in a 3GPP/2 or some other=20 wireless network, or even ethernet? An implementation might just=20 see a PPP driver or an ethernet driver. That says nothing about=20 the underlying technology. >=20 > > This leads to inefficient use of power and network resources=20 > > in some wireless devices. A more efficient way to do things is=20 > > to indicate in the RA whether the host should even try to find > > a DHCP server. I find the current description in 2461/2bis > > sufficient, dynamic and provides enough granularity to allow > > hosts to look for what they need (i.e. addresses or=20 > "other" config). >=20 > Yes, a bit indicating whether to expect a DHCP service at=20 > all might be > useful ... although I, as an implementor, might be tempted to try the > DHCP service anyway in certain circumstances; suppose there are no > advertised prefixes from which to assign SLAAC addresses? =3D> You can try, but my concern is about how often you're going to try. If there are bits that say whether you should try or not and those=20 bits are not set (i.e. no DHCP server in the network), why would you = try? Hesham >=20 > > As a side note, we must not force DHCP to be a default address=20 > > configuration mechanism in IPv6. Stateless address config actually > > provides a very useful and timely way of configuring addresses=20 > > for mobile nodes. > >=20 > > Hesham > >=20 > >=20 > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > > > Behalf Of > > > Ralph Droms > > > Sent: Friday, May 20, 2005 2:34 PM > > > To: ipv6@ietf.org; dhcwg@ietf.org > > > Subject: Re: meta thoughts on m/o bits > > >=20 > > >=20 > > > Well...DHCPv6 doesn't have any better mechanism for announcing > > > availability of a server than does DHCPv4 (which is to=20 > say "none"). > > > There has not been an identified need to push an=20 > announcement of DHCP > > > server availability out to clients. > > >=20 > > > Section 14 of RFC 3315 specifies the retransmission=20 > behavior for DHCP > > > clients. When that behavior is interpreted for Solicit=20 > messages in > > > section 17.1.2, the result is that the DHCP client continues to > > > retransmit Solicit messages at low frequency (once=20 > every 2 minutes) > > > forever. Therefore, the client will eventually contact the=20 > > > DHCP service > > > when a server becomes available. > > >=20 > > > - Ralph > > >=20 > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > > This proposal looks better and easy to understand. However, > > > > > if we just rely on timeout for concluding the=20 > > > unavailabiliy of DHCP server, > > > > > how does the client re-invoke DHCP if the DHCP server is=20 > > > available later in=20 > > > > > time? I think we need one bit to inform the clients=20 > about the > > > > > availabilty of DHCP > > > > > services in the network. > > > >=20 > > > > I would assume that DHC has mechanisms for=20 > discovering when DHC > > > > servers come on line. I.e., the client just sits quietly=20 > > > in background. > > > >=20 > > > > Sure, an RA bit could also signal the availability of=20 > a new server, > > > > but I would first like to be convinced that the existing=20 > > > default DHC > > > > mechanism isn't good enough for handling this case (better=20 > > > not to have > > > > multiple ways of acheiving the same result). > > > >=20 > > > > Thomas > > > >=20 > > > >=20 > > >=20 > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests:=20 > > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=20 > -------------------------------------------------------------------- > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material for the = sole use > of the intended recipient. Any review or distribution by others is = strictly > prohibited. If you are not the intended recipient please contact the = sender > and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 16:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDh0-0000nJ-7r; Fri, 20 May 2005 16:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDJv-0008RC-BO; Fri, 20 May 2005 15:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00860; Fri, 20 May 2005 15:38:05 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDbK-0004uj-EG; Fri, 20 May 2005 15:56:07 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 15:37:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2005 15:36:53 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdbssH2+mYkiCqTVyvr9/puMHYcwAAPLbwAABbcEAAAHq+AA== From: "Soliman, Hesham" To: "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 20 May 2005 19:37:55.0616 (UTC) FILETIME=[6B80EA00:01C55D73] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 May 2005 16:01:53 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Bernie,=20 > > =3D> You can try, but my concern is about how often you're=20 > going to try. > > If there are bits that say whether you should try or not and those=20 > > bits are not set (i.e. no DHCP server in the network), why=20 > > would you try? > =20 > This means that the wiresless operators will get more revenue from > Ralph! >=20 > If the wireless operator isn't using DHCP (or only using stateless), > there's no reason they can't charge for that (stateful) traffic. =3D> :) I don't want them to charge users for Ralph's implementation :) But seriously, charging is one thing, inefficient use of power is=20 another serious problem which can actually reduce revenue because a device doesn't go dormant long enough and runs out of battery=20 instead of using that battery power for what the user actually wants to do. Hesham >=20 > This is the reason why having one (or two) bits in the RA to indicate > whether DHCP should be run are useful. But, those bits are advisory > only. >=20 > - Bernie >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > Behalf Of Soliman, Hesham > > Sent: Friday, May 20, 2005 3:15 PM > > To: Ralph Droms (rdroms) > > Cc: dhcwg@ietf.org; ipv6@ietf.org > > Subject: RE: meta thoughts on m/o bits > >=20 > >=20 > >=20 > > > No one is suggesting DHCP is the "default address configuration > > > mechanism". Let's *please* not go down that discussion path... > >=20 > > =3D> some parts of the discussion were hinting at that, that's=20 > > why I said "side note". I'm glad you're not suggesting that. > >=20 > > >=20 > > > More comments in line. > > >=20 > > > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > > > > In some scenarios there is a danger in the following approach: > > > > - hosts boots > > > > - looks for DHCP server, doesn't find one > > > > - Keeps looking every couple of minutes > > >=20 > > > A client is free to use some other timeout (2 hours instead of 2 > > > minutes?) if it chooses. See sections 5, 14 and 17.1.2 of=20 > > > RFC 3315. I > > > imagine standards bodies for specific environments (3GPP2?)=20 > > > might well > > > mandate different retransmit timeouts, for example, to conserve > > > bandwidth or power. > >=20 > > =3D> It's unrealistic to assume that. An SDO might suggest that but > > how does an implementation know it's in a 3GPP/2 or some other=20 > > wireless network, or even ethernet? An implementation might just=20 > > see a PPP driver or an ethernet driver. That says nothing about=20 > > the underlying technology. > >=20 > > >=20 > > > > This leads to inefficient use of power and network resources=20 > > > > in some wireless devices. A more efficient way to do=20 > things is=20 > > > > to indicate in the RA whether the host should even try to find > > > > a DHCP server. I find the current description in 2461/2bis > > > > sufficient, dynamic and provides enough granularity to allow > > > > hosts to look for what they need (i.e. addresses or=20 > > > "other" config). > > >=20 > > > Yes, a bit indicating whether to expect a DHCP service at=20 > > > all might be > > > useful ... although I, as an implementor, might be tempted=20 > > to try the > > > DHCP service anyway in certain circumstances; suppose=20 > there are no > > > advertised prefixes from which to assign SLAAC addresses? > >=20 > > =3D> You can try, but my concern is about how often you're=20 > going to try. > > If there are bits that say whether you should try or not and those=20 > > bits are not set (i.e. no DHCP server in the network), why=20 > > would you try? > >=20 > > Hesham > >=20 > > >=20 > > > > As a side note, we must not force DHCP to be a=20 > default address=20 > > > > configuration mechanism in IPv6. Stateless address=20 > > config actually > > > > provides a very useful and timely way of configuring=20 > addresses=20 > > > > for mobile nodes. > > > >=20 > > > > Hesham > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: ipv6-bounces@ietf.org=20 > [mailto:ipv6-bounces@ietf.org]On=20 > > > > > Behalf Of > > > > > Ralph Droms > > > > > Sent: Friday, May 20, 2005 2:34 PM > > > > > To: ipv6@ietf.org; dhcwg@ietf.org > > > > > Subject: Re: meta thoughts on m/o bits > > > > >=20 > > > > >=20 > > > > > Well...DHCPv6 doesn't have any better mechanism=20 > for announcing > > > > > availability of a server than does DHCPv4 (which is to=20 > > > say "none"). > > > > > There has not been an identified need to push an=20 > > > announcement of DHCP > > > > > server availability out to clients. > > > > >=20 > > > > > Section 14 of RFC 3315 specifies the retransmission=20 > > > behavior for DHCP > > > > > clients. When that behavior is interpreted for Solicit=20 > > > messages in > > > > > section 17.1.2, the result is that the DHCP client=20 > > continues to > > > > > retransmit Solicit messages at low frequency (once=20 > > > every 2 minutes) > > > > > forever. Therefore, the client will eventually=20 > contact the=20 > > > > > DHCP service > > > > > when a server becomes available. > > > > >=20 > > > > > - Ralph > > > > >=20 > > > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > > > > This proposal looks better and easy to=20 > > understand. However, > > > > > > > if we just rely on timeout for concluding the=20 > > > > > unavailabiliy of DHCP server, > > > > > > > how does the client re-invoke DHCP if the DHCP=20 > server is=20 > > > > > available later in=20 > > > > > > > time? I think we need one bit to inform the clients=20 > > > about the > > > > > > > availabilty of DHCP > > > > > > > services in the network. > > > > > >=20 > > > > > > I would assume that DHC has mechanisms for=20 > > > discovering when DHC > > > > > > servers come on line. I.e., the client just sits quietly=20 > > > > > in background. > > > > > >=20 > > > > > > Sure, an RA bit could also signal the availability of=20 > > > a new server, > > > > > > but I would first like to be convinced that the existing=20 > > > > > default DHC > > > > > > mechanism isn't good enough for handling this=20 > case (better=20 > > > > > not to have > > > > > > multiple ways of acheiving the same result). > > > > > >=20 > > > > > > Thomas > > > > > >=20 > > > > > >=20 > > > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > > > > IETF IPv6 working group mailing list > > > > > > ipv6@ietf.org > > > > > > Administrative Requests:=20 > > > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > >=20 > > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests:=20 > > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=20 > -------------------------------------------------------------------- > > >=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > This email may contain confidential and privileged material=20 > > for the sole use > > > of the intended recipient. Any review or distribution by=20 > > others is strictly > > > prohibited. If you are not the intended recipient please=20 > > contact the sender > > > and delete all copies. > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 17:40:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFEi-0002tv-2z; Fri, 20 May 2005 17:40:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFEg-0002tp-Ml for dhcwg@megatron.ietf.org; Fri, 20 May 2005 17:40:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16749 for ; Fri, 20 May 2005 17:40:48 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZFW5-0001mF-1K for dhcwg@ietf.org; Fri, 20 May 2005 17:58:52 -0400 Received: from [10.187.69.18] (m615e36d0.tmodns.net [208.54.94.97]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id B76C35689B; Fri, 20 May 2005 14:39:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DF36697-99BE-4B43-B537-F40E93D5CA15@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 17:34:44 -0400 To: peter_blatherwick@mitel.com X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "Kostur, Andre" , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 20, 2005, at 1:45 PM, peter_blatherwick@mitel.com wrote: > Any feedback on 60 / 43? Well deployed? Well understood in the > real world? The biggest tragedy of Option 60/43 is that so few client vendors implement it. AFAIK all the server vendors implement it - to my knowledge, the Nominum server and the ISC server do, and I would be shocked if any of the other commercial servers don't. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 17:49:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFNA-0004nK-LY; Fri, 20 May 2005 17:49:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFN9-0004nB-2y for dhcwg@megatron.ietf.org; Fri, 20 May 2005 17:49:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17219 for ; Fri, 20 May 2005 17:49:32 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZFeY-0001yb-JH for dhcwg@ietf.org; Fri, 20 May 2005 18:07:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 18:00:16 -0400 X-IronPort-AV: i="3.93,125,1115006400"; d="scan'208"; a="50420514:sNHT31725054" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KLnH50018827; Fri, 20 May 2005 17:49:21 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 17:49:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 17:49:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3DD7@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdhKe+W9Ldbd5mSA6vzetjf6kXAwAAJQOQ From: "Bernie Volz \(volz\)" To: "Ted Lemon" , X-OriginalArrivalTime: 20 May 2005 21:49:17.0262 (UTC) FILETIME=[C554A6E0:01C55D85] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Cisco does implement them and has for a long time! But the other problem with option 60/43 is that there is only ONE vendor's data that can be exchanged. So, there's no way to communicate multiple vendor's information if the client is a general purpose system and not an "appliance" that does only one thing. That's one reason 124/125 are much more attractive longer term. Though of course there also need to be APIs to the DHCP Client or other means to "set" options to be sent and "get" returned options. - Bernie=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 20, 2005 5:35 PM > To: peter_blatherwick@mitel.com > Cc: Kostur, Andre; dhcwg@ietf.org; Bernie Volz (volz) > Subject: Re: [dhcwg] DHCP options 128-135 in use -- please=20 > place on "Tentatively Assigned" list re. RFC 3942 >=20 > On May 20, 2005, at 1:45 PM, peter_blatherwick@mitel.com wrote: > > Any feedback on 60 / 43? Well deployed? Well understood in the =20 > > real world? >=20 > The biggest tragedy of Option 60/43 is that so few client vendors =20 > implement it. AFAIK all the server vendors implement it - to my =20 > knowledge, the Nominum server and the ISC server do, and I would be =20 > shocked if any of the other commercial servers don't. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 20 19:15:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZGiV-00009i-DZ; Fri, 20 May 2005 19:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZGiT-00009a-SY; Fri, 20 May 2005 19:15:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25767; Fri, 20 May 2005 19:15:38 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZGzu-00045l-0S; Fri, 20 May 2005 19:33:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4KMiEs16748; Fri, 20 May 2005 15:44:14 -0700 X-mProtect: <200505202244> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdrIZsd3; Fri, 20 May 2005 15:44:12 PDT Message-Id: <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 20 May 2005 16:15:13 -0700 To: ipv6@ietf.org From: Bob Hinden In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dhcwg@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, I would like to second the point Jinmei made, that we had something very close to this discussion about a year ago. Also, I am not sure I understand what the problem is regarding knowing when to try using DHCPv6. For practical purposes, if there isn't a router present (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 server either (or it won't be reachable because the router is down). If the "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not set, then it's a pretty good hint that there isn't much sense in trying to use DHCPv6. Is something else needed? Bob _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 21 07:19:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1P-0002MH-Df; Sat, 21 May 2005 07:19:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1N-0002Le-JD; Sat, 21 May 2005 07:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29458; Sat, 21 May 2005 07:19:55 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZMFm-0006MV-3t; Sat, 21 May 2005 01:10:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4L4pYh21381; Sat, 21 May 2005 07:51:34 +0300 Date: Sat, 21 May 2005 07:51:34 +0300 (EEST) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Message-ID: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, 20 May 2005, Bob Hinden wrote: > Also, I am not sure I understand what the problem is regarding knowing when > to try using DHCPv6. For practical purposes, if there isn't a router present > (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 > server either (or it won't be reachable because the router is down). If the > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host > might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not > set, then it's a pretty good hint that there isn't much sense in trying to > use DHCPv6. Actually, the lack of M or O bits is not as good a hint as their existence. If we wanted a _good_ hint about non-existence of DHCPv6 (for addresses or config information), we'd have to have different flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in this network". That allows disambiguation from "Yes, we do have a couple of DHCPv6 servers, but we weren't aware you should configure this stuff in the RAs, because with v4 you don't". But I'm not sure that disambiguation is worth the effort. That said, I support the clarification. In a sense I agree with Thomas et al that the ra-mo-flags spec goes beyond the bare minimum what the IETF specifications must specify -- it documents the policies and behaviours which most vendors would implement in any case, but these kind of knobs have often been left out of our specs. However, as there has been so much confusion and discussion of M/O flags, I think this specification is useful, and also allows vendors (who want to) to implement the knobs in a uniform manner. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 21 09:21:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZTvI-0007yK-7t; Sat, 21 May 2005 09:21:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZTvF-0007xi-3S; Sat, 21 May 2005 09:21:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19816; Sat, 21 May 2005 09:21:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZUCo-0005Kk-Np; Sat, 21 May 2005 09:39:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 May 2005 09:21:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4LDLW4u029625; Sat, 21 May 2005 09:21:33 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 21 May 2005 09:21:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 May 2005 09:21:28 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3E07@xmb-rtp-20a.amer.cisco.com> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVd+f6Mv0pLKGdJTN2ZfxhSRfd5rAACtd1g From: "Bernie Volz \(volz\)" To: "Jari Arkko" , "Soliman, Hesham" X-OriginalArrivalTime: 21 May 2005 13:21:32.0888 (UTC) FILETIME=[018FD580:01C55E08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Look, I'm not advocating that every device run DHCPv6. I think we're all on the same page here - we want some indication of whether to run or not run DHCP, but that is only an indication not a hard requirement. I, as the owner/administrator of a device, should be able to explicitly configure the device to either always run DHCP or never run DHCP. If I chose to run it when there is no service available, so be it. If I chose to no run it when there is a service and it is needed for "full" network access, so be it -- my device may have limited access depending on what stateless allows or doesn't allow. Other than periodic traffic, which in many networks is of no significant consequence (though it *IS* in other networks), there is no harm if you err on the side or running DHCP ALWAYS. If on the other hand you do not run it when it is needed for full access ... There are many heuristics that can be used by devices to "guess" at whether DHCP might be useful to run or not. For example, if there are prefixes advertised but none are stateless, run DHCP. If all advertised prefixes are stateless, don't run DHCP (at least for stateful addresses). And, clients could be smarter about the retransmission algorithms they use -- such as using longer "probe" intervals if they fail to get a response. Or stopping the probes after a period of time.=20 Sure, all of this takes some processing overhead and that's why I think we all feel that having a bit or two bits as hints makes a lot of sense. I believe some people were very concerned if a router is misconfigured. Personally, I don't get that issue at all. If an administrator doesn't configure other things properly, the network may or may not work either. So, why are these bits any different than the hundreds of other parameters and knobs? Perhaps we should be discussing what routers might do to figure out how to automatically determine the setting of these bits or "alarm" if the bit is potentially set incorrectly? One simple rule is if the router is configured to be a relay agent, the bit(s) should be set. (At least if we take DHCPv4 networks as a model, this will likely properly configure a good portion of the routers correctly.) Perhaps the router should periodically probe for a DHCP server (via the link-local multicast address). If one is discovered and the bit(s) are clear, either there is a rogue server on the network OR the bit(s) wasn't configured correctly. If no server responds after some number of attempts and the bit(s) are set, either the server is down (in which case clearing the bit(s) in the RA might not be a big issue until the server returns -- modulo the probe interval) or the bits were set incorrectly and some type of "alarm" is reasonable. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Jari Arkko > Sent: Saturday, May 21, 2005 12:57 AM > To: Soliman, Hesham > Cc: dhcwg@ietf.org; ipv6@ietf.org; Bernie Volz (volz); Ralph=20 > Droms (rdroms) > Subject: Re: meta thoughts on m/o bits >=20 > Soliman, Hesham wrote: >=20 > >Hi Bernie,=20 > > > > > > =3D> You can try, but my concern is about how often you're=20 > > > going to try. > > > > If there are bits that say whether you should try or=20 > not and those=20 > > > > bits are not set (i.e. no DHCP server in the network), why=20 > > > > would you try? > > > =20 > > > This means that the wiresless operators will get more revenue from > > > Ralph! > > >=20 > > > If the wireless operator isn't using DHCP (or only using=20 > stateless), > > > there's no reason they can't charge for that (stateful) traffic. > > > >=3D> :) I don't want them to charge users for Ralph's implementation = :) > >But seriously, charging is one thing, inefficient use of power is=20 > >another serious problem which can actually reduce revenue because > >a device doesn't go dormant long enough and runs out of battery=20 > >instead of using that battery power for what the user actually wants > >to do. > > =20 > > > I tend to agree with Hesham that we should attempt to design > our protocols so that unnecessary periodic probing over wireless > is minimized. One thing that should be kept in mind is that most > people want their devices to be always on and reachable, but yet > they might actually use them for something only a very small > fraction of the time. Even a tiny amount of traffic during the > inactive period may thus result in a relatively large impact > when you compare it to actual useful traffic. This in turn > translates to battery lifetimes and cost for the users. >=20 > --Jari >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 21 13:53:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZYAV-0004II-KP; Sat, 21 May 2005 13:53:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZYAT-0004Hl-Rq for dhcwg@megatron.ietf.org; Sat, 21 May 2005 13:53:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10093 for ; Sat, 21 May 2005 13:53:43 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZYS4-0003RT-Cs for dhcwg@ietf.org; Sat, 21 May 2005 14:11:57 -0400 Received: from [10.0.1.34] (dpc6935208055.direcpc.com [69.35.208.55]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 262C5568EB; Sat, 21 May 2005 10:53:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DF36697-99BE-4B43-B537-F40E93D5CA15@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 17:34:44 -0400 To: peter_blatherwick@mitel.com X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.4 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "Kostur, Andre" , "Bernie Volz \(volz\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 20, 2005, at 1:45 PM, peter_blatherwick@mitel.com wrote: > Any feedback on 60 / 43? Well deployed? Well understood in the > real world? The biggest tragedy of Option 60/43 is that so few client vendors implement it. AFAIK all the server vendors implement it - to my knowledge, the Nominum server and the ISC server do, and I would be shocked if any of the other commercial servers don't. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun May 22 09:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZqbF-0003AJ-DU; Sun, 22 May 2005 09:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1J-0002Jg-AS; Sat, 21 May 2005 07:19:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29380; Sat, 21 May 2005 07:19:50 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZMKo-0000iN-IJ; Sat, 21 May 2005 01:15:40 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 728D189869; Sat, 21 May 2005 07:56:46 +0300 (EEST) Message-ID: <428EBF9C.8040008@kolumbus.fi> Date: Sat, 21 May 2005 07:57:00 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 22 May 2005 09:34:35 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: [dhcwg] Re: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Soliman, Hesham wrote: >Hi Bernie, > > > > => You can try, but my concern is about how often you're > > going to try. > > > If there are bits that say whether you should try or not and those > > > bits are not set (i.e. no DHCP server in the network), why > > > would you try? > > > > This means that the wiresless operators will get more revenue from > > Ralph! > > > > If the wireless operator isn't using DHCP (or only using stateless), > > there's no reason they can't charge for that (stateful) traffic. > >=> :) I don't want them to charge users for Ralph's implementation :) >But seriously, charging is one thing, inefficient use of power is >another serious problem which can actually reduce revenue because >a device doesn't go dormant long enough and runs out of battery >instead of using that battery power for what the user actually wants >to do. > > I tend to agree with Hesham that we should attempt to design our protocols so that unnecessary periodic probing over wireless is minimized. One thing that should be kept in mind is that most people want their devices to be always on and reachable, but yet they might actually use them for something only a very small fraction of the time. Even a tiny amount of traffic during the inactive period may thus result in a relatively large impact when you compare it to actual useful traffic. This in turn translates to battery lifetimes and cost for the users. --Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 07:26:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaB4j-0000M6-BO; Mon, 23 May 2005 07:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9AN-00049p-9g; Mon, 23 May 2005 05:24:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07026; Mon, 23 May 2005 05:24:05 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da9SJ-0008Jc-6A; Mon, 23 May 2005 05:42:40 -0400 Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4N9O3pU031423; Mon, 23 May 2005 12:24:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:03 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 12:24:02 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D2C789A@esebe100.NOE.Nokia.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVd+PXnWeuIho+8Q9mlrxw/wNvCJgBZxaYA To: , X-OriginalArrivalTime: 23 May 2005 09:24:03.0043 (UTC) FILETIME=[28D18B30:01C55F79] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 23 May 2005 07:26:24 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Pekka and Bob, > On Fri, 20 May 2005, Bob Hinden wrote: > > Also, I am not sure I understand what the problem is regarding = knowing when=20 > > to try using DHCPv6. For practical purposes, if there isn't a = router present=20 > > (indicated by the RAs it sends) is very unlikely that there will be = a DHCPv6=20 > > server either (or it won't be reachable because the router is down). = If the=20 > > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a = host=20 > > might try to use DHCPv6 and see what it gets. If the "m" or "o" = bits are not=20 > > set, then it's a pretty good hint that there isn't much sense in = trying to=20 > > use DHCPv6. >=20 > Actually, the lack of M or O bits is not as good a hint as their=20 > existence. If we wanted a _good_ hint about non-existence of DHCPv6=20 > (for addresses or config information), we'd have to have different=20 > flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in = > this network". That allows disambiguation from "Yes, we do have a=20 > couple of DHCPv6 servers, but we weren't aware you should configure=20 > this stuff in the RAs, because with v4 you don't". >=20 > But I'm not sure that disambiguation is worth the effort. >=20 > That said, I support the clarification. In a sense I agree with=20 > Thomas et al that the ra-mo-flags spec goes beyond the bare minimum=20 > what the IETF specifications must specify -- it documents the policies = > and behaviours which most vendors would implement in any case, but=20 > these kind of knobs have often been left out of our specs. However,=20 > as there has been so much confusion and discussion of M/O flags, I=20 > think this specification is useful, and also allows vendors (who want=20 > to) to implement the knobs in a uniform manner. I'll have to re-read the draft, but I think that documenting the M/O = bits sufficiently so that nodes and networks will be able to interoperate in a reasonable way. Documenting the basic policies and rules, IMO, are a good thing. Would a BCP-type document be a reasonable way to=20 achieve this? John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 07:26:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaB4j-0000MV-MB; Mon, 23 May 2005 07:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9AU-0004AV-Qu; Mon, 23 May 2005 05:24:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07029; Mon, 23 May 2005 05:24:12 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da9SQ-0008Jh-O8; Mon, 23 May 2005 05:42:48 -0400 Received: from esebh108.NOE.Nokia.com ([172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4N9MIDZ008424; Mon, 23 May 2005 12:22:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:08 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 12:24:05 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVd+gA/g6lcDZcHSPy124tMuAAX2gBZm7uw To: , X-OriginalArrivalTime: 23 May 2005 09:24:06.0277 (UTC) FILETIME=[2ABF0350:01C55F79] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 23 May 2005 07:26:24 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org, volz@cisco.com, rdroms@cisco.com Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Jari & Hesham, > >=3D> :) I don't want them to charge users for Ralph's implementation = :) > >But seriously, charging is one thing, inefficient use of power is=20 > >another serious problem which can actually reduce revenue because > >a device doesn't go dormant long enough and runs out of battery=20 > >instead of using that battery power for what the user actually wants > >to do. > > =20 > > > I tend to agree with Hesham that we should attempt to design > our protocols so that unnecessary periodic probing over wireless > is minimized. One thing that should be kept in mind is that most > people want their devices to be always on and reachable, but yet > they might actually use them for something only a very small > fraction of the time. Even a tiny amount of traffic during the > inactive period may thus result in a relatively large impact > when you compare it to actual useful traffic. This in turn > translates to battery lifetimes and cost for the users. Basically, what I think we'd like is that if a device has a working address and is 'attached' to a network, it should probably use that address and only probe upon some failure event. When the device shows up to a new network, it can probe and if it gets a DHCP address, then use it, and update the address before the lease expires. If the device gets a valid address via autoconfig, then it should continue to use that. It doesn't make much sense that a node should continually verify if it should use a DHCP address if it has an otherwise working address. Note that many applications will run sometime of watchdog or heartbeat to ensure that application is still alive on both ends. If this fails, that might be a clue to check if the IP address is still valid. I agree that having probing at multiple layers is a bad design, IMO. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 07:46:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBOC-0002D7-W6; Mon, 23 May 2005 07:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBOA-0002CL-D4; Mon, 23 May 2005 07:46:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16535; Mon, 23 May 2005 07:46:29 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaBg6-0000eT-Mi; Mon, 23 May 2005 08:05:05 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 07:46:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4NBkGl6008830; Mon, 23 May 2005 07:46:16 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 07:46:15 -0400 Received: from 10.86.240.55 ([10.86.240.55]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 May 2005 11:46:15 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 07:46:38 -0400 Subject: Re: [dhcwg] RE: meta thoughts on m/o bits From: Ralph Droms To: john.loughney@nokia.com In-Reply-To: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 07:46:37 -0400 Message-Id: <1116848797.5528.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 11:46:15.0901 (UTC) FILETIME=[06CC58D0:01C55F8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, jari.arkko@kolumbus.fi, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org John - My understanding is that the selection of SLAAC addresses is separate from the use of DHCP; that is, a host may be in a scenario in which it uses both an address chosen through SLAAC and an address assigned through a DHCP message exchange. So, the availability of a SLAAC address should not affect the use of DHCP. - Ralph On Mon, 2005-05-23 at 12:24 +0300, john.loughney@nokia.com wrote: > Jari & Hesham, > > > >=> :) I don't want them to charge users for Ralph's implementation :) > > >But seriously, charging is one thing, inefficient use of power is > > >another serious problem which can actually reduce revenue because > > >a device doesn't go dormant long enough and runs out of battery > > >instead of using that battery power for what the user actually wants > > >to do. > > > > > > > > I tend to agree with Hesham that we should attempt to design > > our protocols so that unnecessary periodic probing over wireless > > is minimized. One thing that should be kept in mind is that most > > people want their devices to be always on and reachable, but yet > > they might actually use them for something only a very small > > fraction of the time. Even a tiny amount of traffic during the > > inactive period may thus result in a relatively large impact > > when you compare it to actual useful traffic. This in turn > > translates to battery lifetimes and cost for the users. > > Basically, what I think we'd like is that if a device has a working > address and is 'attached' to a network, it should probably use that > address and only probe upon some failure event. When the device > shows up to a new network, it can probe and if it gets a DHCP address, > then use it, and update the address before the lease expires. If > the device gets a valid address via autoconfig, then it should continue > to use that. It doesn't make much sense that a node should continually > verify if it should use a DHCP address if it has an otherwise working > address. > > Note that many applications will run sometime of watchdog or heartbeat > to ensure that application is still alive on both ends. If this fails, > that might be a clue to check if the IP address is still valid. I > agree that having probing at multiple layers is a bad design, IMO. > > 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-bounces@ietf.org Mon May 23 07:50:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBST-0002x9-B8; Mon, 23 May 2005 07:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBSQ-0002w2-6V; Mon, 23 May 2005 07:50:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16966; Mon, 23 May 2005 07:50:53 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaBkN-0000l4-HV; Mon, 23 May 2005 08:09:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 07:50:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4NBoY52016172; Mon, 23 May 2005 07:50:41 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 07:50:36 -0400 Received: from 10.86.240.55 ([10.86.240.55]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 May 2005 11:50:35 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 07:50:58 -0400 Subject: Re: [dhcwg] RE: meta thoughts on m/o bits From: Ralph Droms To: john.loughney@nokia.com In-Reply-To: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 07:50:58 -0400 Message-Id: <1116849058.5528.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 11:50:36.0106 (UTC) FILETIME=[A1E47AA0:01C55F8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, jari.arkko@kolumbus.fi, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org John - I agree that in lieu of some failure or otherwise special condition, devices should use the mechanisms built into SLAAC and DHCP (address lifetimes) to control the use and assignment of addresses. I think the DNAv6 work may have some impact on this discussion as providing a more reliable mechanism for detecting when a host has changed links and should therefore consider re-checking its addresses. - Ralph On Mon, 2005-05-23 at 12:24 +0300, john.loughney@nokia.com wrote: > Jari & Hesham, > > > >=> :) I don't want them to charge users for Ralph's implementation :) > > >But seriously, charging is one thing, inefficient use of power is > > >another serious problem which can actually reduce revenue because > > >a device doesn't go dormant long enough and runs out of battery > > >instead of using that battery power for what the user actually wants > > >to do. > > > > > > > > I tend to agree with Hesham that we should attempt to design > > our protocols so that unnecessary periodic probing over wireless > > is minimized. One thing that should be kept in mind is that most > > people want their devices to be always on and reachable, but yet > > they might actually use them for something only a very small > > fraction of the time. Even a tiny amount of traffic during the > > inactive period may thus result in a relatively large impact > > when you compare it to actual useful traffic. This in turn > > translates to battery lifetimes and cost for the users. > > Basically, what I think we'd like is that if a device has a working > address and is 'attached' to a network, it should probably use that > address and only probe upon some failure event. When the device > shows up to a new network, it can probe and if it gets a DHCP address, > then use it, and update the address before the lease expires. If > the device gets a valid address via autoconfig, then it should continue > to use that. It doesn't make much sense that a node should continually > verify if it should use a DHCP address if it has an otherwise working > address. > > Note that many applications will run sometime of watchdog or heartbeat > to ensure that application is still alive on both ends. If this fails, > that might be a clue to check if the IP address is still valid. I > agree that having probing at multiple layers is a bad design, IMO. > > 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-bounces@ietf.org Mon May 23 08:53:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCR5-0001c6-5v; Mon, 23 May 2005 08:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCR0-0001by-6r; Mon, 23 May 2005 08:53:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21584; Mon, 23 May 2005 08:53:29 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCiy-0002MM-V3; Mon, 23 May 2005 09:12:05 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id AFD3C109; Mon, 23 May 2005 08:51:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 08:53:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: meta thoughts on m/o bits Date: Mon, 23 May 2005 08:53:12 -0400 Message-ID: <936A4045C332714F975800409DE092404A0685@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: meta thoughts on m/o bits Thread-Index: AcVfjbnM79g3LMLJRxe5dyBP+G2CugACJkVA From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 23 May 2005 12:53:16.0459 (UTC) FILETIME=[633CCFB0:01C55F96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: H.Soliman@flarion.com, jari.arkko@kolumbus.fi, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is my understanding too and the way it should be implemented too. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Monday, May 23, 2005 7:47 AM > To: john.loughney@nokia.com > Cc: H.Soliman@flarion.com; jari.arkko@kolumbus.fi;=20 > ipv6@ietf.org; volz@cisco.com; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: meta thoughts on m/o bits >=20 > John - My understanding is that the selection of SLAAC addresses is > separate from the use of DHCP; that is, a host may be in a scenario in > which it uses both an address chosen through SLAAC and an address > assigned through a DHCP message exchange. So, the availability of a > SLAAC address should not affect the use of DHCP. >=20 > - Ralph >=20 > On Mon, 2005-05-23 at 12:24 +0300, john.loughney@nokia.com wrote:=20 > > Jari & Hesham, > >=20 > > > >=3D> :) I don't want them to charge users for Ralph's=20 > implementation :) > > > >But seriously, charging is one thing, inefficient use of=20 > power is=20 > > > >another serious problem which can actually reduce revenue because > > > >a device doesn't go dormant long enough and runs out of battery=20 > > > >instead of using that battery power for what the user=20 > actually wants > > > >to do. > > > > =20 > > > > > > > I tend to agree with Hesham that we should attempt to design > > > our protocols so that unnecessary periodic probing over wireless > > > is minimized. One thing that should be kept in mind is that most > > > people want their devices to be always on and reachable, but yet > > > they might actually use them for something only a very small > > > fraction of the time. Even a tiny amount of traffic during the > > > inactive period may thus result in a relatively large impact > > > when you compare it to actual useful traffic. This in turn > > > translates to battery lifetimes and cost for the users. > >=20 > > Basically, what I think we'd like is that if a device has a working > > address and is 'attached' to a network, it should probably use that > > address and only probe upon some failure event. When the device > > shows up to a new network, it can probe and if it gets a=20 > DHCP address, > > then use it, and update the address before the lease expires. If > > the device gets a valid address via autoconfig, then it=20 > should continue > > to use that. It doesn't make much sense that a node should=20 > continually > > verify if it should use a DHCP address if it has an=20 > otherwise working > > address. > >=20 > > Note that many applications will run sometime of watchdog=20 > or heartbeat > > to ensure that application is still alive on both ends. If=20 > this fails, > > that might be a clue to check if the IP address is still valid. I > > agree that having probing at multiple layers is a bad design, IMO. > >=20 > > John > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 08:57:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCVI-0002Gl-JR; Mon, 23 May 2005 08:57:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCVG-0002G4-4I; Mon, 23 May 2005 08:57:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22015; Mon, 23 May 2005 08:57:53 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCnE-0002UT-Ru; Mon, 23 May 2005 09:16:29 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8C626FE; Mon, 23 May 2005 08:55:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 08:57:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 08:57:41 -0400 Message-ID: <936A4045C332714F975800409DE092404A068B@tayexc14.americas.cpqcorp.net> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVflh0XeIjvY7pMRzypU2y4/5aAWQAAH2uQ From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Ralph Droms" X-OriginalArrivalTime: 23 May 2005 12:57:44.0668 (UTC) FILETIME=[031A41C0:01C55F97] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I don't know what is complex here this is all obvious today with current wording. Even if DHCPv6 is used for addresses, statless is still required as a note too. This is not an implementation problem I see at all. =20 Of those speaking how many of you when writing your code got stuck and that might help this discussion? This has been going on to long. Our specs need to work whether someone uses them or not that is not our job here. =20 thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Iljitsch van Beijnum > Sent: Monday, May 23, 2005 8:48 AM > To: Ralph Droms > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: Re: meta thoughts on m/o bits >=20 > On 20-mei-2005, at 21:06, Ralph Droms wrote: >=20 > >> In some scenarios there is a danger in the following approach: > >> - hosts boots > >> - looks for DHCP server, doesn't find one > >> - Keeps looking every couple of minutes >=20 > Yes, this would clearly be harmful in cases where hosts both use =20 > DHCPv6 and stateless autoconfiguration, but no DHCPv6 server is =20 > available. This especially adds up when there are many hosts on the =20 > subnet. >=20 > > A client is free to use some other timeout (2 hours instead of 2 > > minutes?) if it chooses. >=20 > How is this useful? Either I want to know that a DHCPv6 server has =20 > become available, so waiting 2 hours is way too long, or I don't =20 > care, so why bother checking in the first place? >=20 > The situation where a server broadcasts its existence makes=20 > MUCH more =20 > sense. >=20 > But the real question is: how do we know we want to use=20 > DHCPv6 in the =20 > first place? Obviously in many cases the answer is simple: yes, I =20 > want it all the time, or no, I never want it. >=20 > But suppose some networks adopt DHCPv6 in lieu of stateless =20 > autoconfiguration for reasons that make sense to them (and work =20 > elsewhere, such as shim6, _may_ make this a somewhat more likely =20 > situation). It would then make sense for a laptop or similar client =20 > to have both stateless autoconfiguration and DHCPv6 on board for =20 > autoconfiguration. However, such a client wouldn't have any idea =20 > about the availability of either mechanism or their=20 > preference. Since =20 > presumably, DHCPv6 won't be available in many cases, an=20 > agnostic host =20 > wouldn't want to wait for DHCPv6 to fail when stateless=20 > autoconfig is =20 > available. On the other hand, some admins may strongly prefer hosts =20 > to use DHCPv6, but provide stateless autoconfig as a fallback for =20 > hosts that don't support DHCPv6. In that case, it would be better to =20 > ignore stateless autoconfig altogether when DHCPv6 works. The real =20 > problems start when DHCPv6 is preferred, but there is some kind of =20 > failure. Obviously the host should use stateless autoconfig in the =20 > mean time, but it would be useful if it were to switch to DHCPv6 as =20 > soon as the server becomes available. >=20 > So what we really need is a mechanism that says: >=20 > - DHCPv6 isn't available so don't bother with it > - DHCPv6 is available, but use stateless autoconfig unless you can't/=20 > won't > - DHCPv6 is available and equal to stateless autoconfig, use either =20 > but no need to use both > - DHCPv6 is available and equal to stateless autoconfig, use both > - DHCPv6 is available and preferred, use it exclusively if you can >=20 > Something similar is probably needed for the O flag. >=20 > In addition, it would be useful to have some kind of flag that =20 > indicates that the DHCPv6 server status has changed so hosts should =20 > refresh their leases and other information. >=20 > Obviously all of this can't be accommodated with two bits in RAs. So =20 > we can: >=20 > - forget the whole thing and let the implementers/admins figure it out > - hammer on it until it fits in the m and o bits > - come up with an RA/ND option that has room for all of this >=20 > (It would be cool to find a way to integrate DHCPv6 and RAs to some =20 > degree, though. For instance, by allowing DHCP options in RA options.) >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 12:49:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaG7L-0003Q0-C7; Mon, 23 May 2005 12:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaG7K-0003Pn-4O; Mon, 23 May 2005 12:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13146; Mon, 23 May 2005 12:49:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGPJ-0003IU-TZ; Mon, 23 May 2005 13:08:03 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4NGHiT08143; Mon, 23 May 2005 09:17:44 -0700 X-mProtect: <200505231617> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdCBGJ0h; Mon, 23 May 2005 09:17:42 PDT Message-Id: <6.2.1.2.2.20050523093529.0282cd70@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 23 May 2005 09:48:50 -0700 To: Pekka Savola From: Bob Hinden In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Pekka, >Actually, the lack of M or O bits is not as good a hint as their >existence. If we wanted a _good_ hint about non-existence of DHCPv6 (for >addresses or config information), we'd have to have different flag(s) like >"Yes, I'm aware of what DHCPv6 is, but we don't use it in this >network". That allows disambiguation from "Yes, we do have a couple of >DHCPv6 servers, but we weren't aware you should configure this stuff in >the RAs, because with v4 you don't". This still seems to be to be fairly equivalent. I think the important function is if there is a DHCPv6 server and the site want the clients to use it, then they should set the "m" and "o" bits. I don't see very much value in conveying the negatives (e.g., we have a DHCPv6 server, but we don't want the clients to use it, we don't have a DHCPv6 server so don't try looking for one, we didn't set up a relay, etc., etc.). >But I'm not sure that disambiguation is worth the effort. Agreed. >That said, I support the clarification. In a sense I agree with Thomas et >al that the ra-mo-flags spec goes beyond the bare minimum what the IETF >specifications must specify -- it documents the policies and behaviours >which most vendors would implement in any case, but these kind of knobs >have often been left out of our specs. However, as there has been so much >confusion and discussion of M/O flags, I think this specification is >useful, and also allows vendors (who want to) to implement the knobs in a >uniform manner. Part of me is starting to think that we might be better off waiting for there to be more operational experience with deployments of DHCPv6 to see how much confusion there really is. I agree it is good for vendors to implement similar knobs, but I wonder how much of a problem there really is. Bob _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 13:15:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGWY-0006AD-5x; Mon, 23 May 2005 13:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGWV-00069e-FD; Mon, 23 May 2005 13:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15496; Mon, 23 May 2005 13:15:24 -0400 (EDT) Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGoV-0004Q2-EY; Mon, 23 May 2005 13:34:04 -0400 Received: from alerion.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id j4NHFBp16502; Mon, 23 May 2005 10:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id D0E093F0021; Mon, 23 May 2005 10:15:11 -0700 (PDT) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13309-10; Mon, 23 May 2005 10:15:10 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id C09AA3F0020; Mon, 23 May 2005 10:15:10 -0700 (PDT) From: Tim Hartrick To: Bob Hinden In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1116868160.22946.13.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 May 2005 10:09:20 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@mentat.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bob, On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > Part of me is starting to think that we might be better off waiting for > there to be more operational experience with deployments of DHCPv6 to see > how much confusion there really is. I agree it is good for vendors to > implement similar knobs, but I wonder how much of a problem there really is. > More than part of me is thinking this. It seems to me that there is a continuing confusion about how these bits interact with local decisions by the administrator of a specific machine or network. People are asking questions like "What happens if the M and/or O bits are clear but there is a DHCP server?" or "What happens if the M and/or O bits are clear but the client wants to use DHCP anyway" or "What happens if the M and/or O bits are set and the client doesn't want to run DHCP". None of these questions are in the realm of protocol design. Clearly, local administrators will do as they please with their machines. In this respect the M and O bits have never been anything but strong hints as to what the client should do. The client is always free to ignore the hints. Further network administrators are free to misconfigure their networks as they please. The current text describing these bits is clear almost to the point of being infantile. This isn't an indictment of the authors. Rather it is an indictment of attempts to enforce system configuration and management rules via protocol specifications. This is impossible. We should stop trying. tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 14:22:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHYw-0006Ty-2c; Mon, 23 May 2005 14:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHYs-0006Sw-Se; Mon, 23 May 2005 14:21:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24089; Mon, 23 May 2005 14:21:57 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHqu-0007Hz-Dp; Mon, 23 May 2005 14:40:36 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 May 2005 11:21:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4NIKv3w028585; Mon, 23 May 2005 11:21:46 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:21:45 -0400 Received: from 10.86.242.29 ([10.86.242.29]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 May 2005 18:21:44 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 14:22:09 -0400 Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt From: Ralph Droms To: Pekka Savola In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 08:50:44 -0400 Message-Id: <1116852645.5655.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 18:21:45.0156 (UTC) FILETIME=[46895040:01C55FC4] X-Spam-Score: 0.7 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sat, 2005-05-21 at 07:51 +0300, Pekka Savola wrote: > On Fri, 20 May 2005, Bob Hinden wrote: > > Also, I am not sure I understand what the problem is regarding knowing when > > to try using DHCPv6. For practical purposes, if there isn't a router present > > (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 > > server either (or it won't be reachable because the router is down). If the > > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host > > might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not > > set, then it's a pretty good hint that there isn't much sense in trying to > > use DHCPv6. > > Actually, the lack of M or O bits is not as good a hint as their > existence. If we wanted a _good_ hint about non-existence of DHCPv6 > (for addresses or config information), we'd have to have different > flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in > this network". That allows disambiguation from "Yes, we do have a > couple of DHCPv6 servers, but we weren't aware you should configure > this stuff in the RAs, because with v4 you don't". Huh? > But I'm not sure that disambiguation is worth the effort. > > That said, I support the clarification. In a sense I agree with > Thomas et al that the ra-mo-flags spec goes beyond the bare minimum > what the IETF specifications must specify -- it documents the policies > and behaviours which most vendors would implement in any case, but > these kind of knobs have often been left out of our specs. However, > as there has been so much confusion and discussion of M/O flags, I > think this specification is useful, and also allows vendors (who want > to) to implement the knobs in a uniform manner. So which do you recomend - a minimum spec like Bob and Thomas have suggested or a more detailed spec like the current ra-mo draft? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 14:46:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHwd-0001Cc-TL; Mon, 23 May 2005 14:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHwb-0001AM-4x; Mon, 23 May 2005 14:46:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26606; Mon, 23 May 2005 14:46:28 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIEc-0008Dt-5E; Mon, 23 May 2005 15:05:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 14:46:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4NIjdle014215; Mon, 23 May 2005 14:46:16 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:46:12 -0400 Received: from 10.86.242.29 ([10.86.242.29]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 May 2005 18:46:12 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 14:46:36 -0400 From: Ralph Droms To: tim@mentat.com In-Reply-To: <1116868160.22946.13.camel@feller> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <1116868160.22946.13.camel@feller> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 14:46:36 -0400 Message-Id: <1116873996.5397.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 18:46:12.0756 (UTC) FILETIME=[B14B4D40:01C55FC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Tim - I agree 100% with your message. - Ralph On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote: > > Bob, > > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > > > Part of me is starting to think that we might be better off waiting for > > there to be more operational experience with deployments of DHCPv6 to see > > how much confusion there really is. I agree it is good for vendors to > > implement similar knobs, but I wonder how much of a problem there really is. > > > > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What happens if the M > and/or O bits are set and the client doesn't want to run DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol specifications. > This is impossible. We should stop trying. > > > > > tim > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 14:50:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaI00-0001Vt-Mv; Mon, 23 May 2005 14:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHzx-0001Tt-RB; Mon, 23 May 2005 14:49:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26888; Mon, 23 May 2005 14:49:56 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIHy-0008LM-MI; Mon, 23 May 2005 15:08:35 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 14:49:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4NInXlC015561; Mon, 23 May 2005 14:49:45 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 14:49:31 -0400 Received: from 10.86.242.29 ([10.86.242.29]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 May 2005 18:49:31 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 14:49:56 -0400 From: Ralph Droms To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050523093529.0282cd70@mailhost.iprg.nokia.com> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <6.2.1.2.2.20050523093529.0282cd70@mailhost.iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 14:49:55 -0400 Message-Id: <1116874195.5397.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 18:49:31.0990 (UTC) FILETIME=[280BFF60:01C55FC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bob - we ought to see what other standards bodies (for example, CableLabs) identify as address assignment requirements and design as IPv6 deployment architectures. - Ralph On Mon, 2005-05-23 at 09:48 -0700, Bob Hinden wrote: > Part of me is starting to think that we might be better off waiting for > there to be more operational experience with deployments of DHCPv6 to see > how much confusion there really is. I agree it is good for vendors to > implement similar knobs, but I wonder how much of a problem there really is. > > Bob > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 14:55:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaI4w-0002n0-KB; Mon, 23 May 2005 14:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaI4u-0002mS-R9; Mon, 23 May 2005 14:55:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27602; Mon, 23 May 2005 14:55:03 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIMv-00009I-Ee; Mon, 23 May 2005 15:13:42 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 May 2005 14:54:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 14:53:46 -0400 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVfyB8xw8gNFS4WQhiWgKmvdj5E3AAAJe6Q From: "Soliman, Hesham" To: "Ralph Droms" , X-OriginalArrivalTime: 23 May 2005 18:54:52.0645 (UTC) FILETIME=[E72C1150:01C55FC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Make that 200 %. Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Ralph Droms > Sent: Monday, May 23, 2005 2:47 PM > To: tim@mentat.com > Cc: dhcwg@ietf.org; Bob Hinden; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 >=20 > Tim - I agree 100% with your message. >=20 > - Ralph >=20 > On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote: > >=20 > > Bob, > >=20 > > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > >=20 > > > Part of me is starting to think that we might be better=20 > off waiting for=20 > > > there to be more operational experience with deployments=20 > of DHCPv6 to see=20 > > > how much confusion there really is. I agree it is good=20 > for vendors to=20 > > > implement similar knobs, but I wonder how much of a=20 > problem there really is. > > >=20 > >=20 > > More than part of me is thinking this. It seems to me=20 > that there is a > > continuing confusion about how these bits interact with=20 > local decisions > > by the administrator of a specific machine or network. People are > > asking questions like "What happens if the M and/or O bits=20 > are clear but > > there is a DHCP server?" or "What happens if the M and/or=20 > O bits are > > clear but the client wants to use DHCP anyway" or "What=20 > happens if the M > > and/or O bits are set and the client doesn't want to run=20 > DHCP". None of > > these questions are in the realm of protocol design. =20 > Clearly, local > > administrators will do as they please with their machines. In this > > respect the M and O bits have never been anything but=20 > strong hints as to > > what the client should do. The client is always free to ignore the > > hints. Further network administrators are free to=20 > misconfigure their > > networks as they please. The current text describing these bits is > > clear almost to the point of being infantile. This isn't=20 > an indictment > > of the authors. Rather it is an indictment of attempts to enforce > > system configuration and management rules via protocol=20 > specifications.=20 > > This is impossible. We should stop trying. > >=20 > >=20 > >=20 > >=20 > > tim > >=20 > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 15:16:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIPV-0006Ph-DW; Mon, 23 May 2005 15:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIPT-0006PW-VE; Mon, 23 May 2005 15:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00351; Mon, 23 May 2005 15:16:18 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIhV-0000vO-T4; Mon, 23 May 2005 15:34:58 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id AE3DF20000DF; Mon, 23 May 2005 15:16:06 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:16:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 15:16:03 -0400 Message-ID: <936A4045C332714F975800409DE092404A08DD@tayexc14.americas.cpqcorp.net> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVft50DzN4ETYLkQsSSw22UvrCK7QAE/bcg From: "Bound, Jim" To: "Bob Hinden" , "Pekka Savola" X-OriginalArrivalTime: 23 May 2005 19:16:06.0607 (UTC) FILETIME=[DE833DF0:01C55FCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bob, THere is no problem. The site owns the router configuration and the network admins are gods of rules. If the site sets the m bit the client is told go look for dhcpv6. if not set don't bother. If o set go look for configs. Pretty simple and I suspect people are looking for away to avoid clients obeying the mandate from the router and the site. We should not support that at all or work on it. The rules are clear. thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bob Hinden > Sent: Monday, May 23, 2005 12:49 PM > To: Pekka Savola > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt=20 >=20 > Pekka, >=20 > >Actually, the lack of M or O bits is not as good a hint as their=20 > >existence. If we wanted a _good_ hint about non-existence=20 > of DHCPv6 (for=20 > >addresses or config information), we'd have to have=20 > different flag(s) like=20 > >"Yes, I'm aware of what DHCPv6 is, but we don't use it in this=20 > >network". That allows disambiguation from "Yes, we do have=20 > a couple of=20 > >DHCPv6 servers, but we weren't aware you should configure=20 > this stuff in=20 > >the RAs, because with v4 you don't". >=20 > This still seems to be to be fairly equivalent. I think the=20 > important=20 > function is if there is a DHCPv6 server and the site want the=20 > clients to=20 > use it, then they should set the "m" and "o" bits. I don't=20 > see very much=20 > value in conveying the negatives (e.g., we have a DHCPv6=20 > server, but we=20 > don't want the clients to use it, we don't have a DHCPv6=20 > server so don't=20 > try looking for one, we didn't set up a relay, etc., etc.). >=20 > >But I'm not sure that disambiguation is worth the effort. >=20 > Agreed. >=20 > >That said, I support the clarification. In a sense I agree=20 > with Thomas et=20 > >al that the ra-mo-flags spec goes beyond the bare minimum=20 > what the IETF=20 > >specifications must specify -- it documents the policies and=20 > behaviours=20 > >which most vendors would implement in any case, but these=20 > kind of knobs=20 > >have often been left out of our specs. However, as there=20 > has been so much=20 > >confusion and discussion of M/O flags, I think this specification is=20 > >useful, and also allows vendors (who want to) to implement=20 > the knobs in a=20 > >uniform manner. >=20 > Part of me is starting to think that we might be better off=20 > waiting for=20 > there to be more operational experience with deployments of=20 > DHCPv6 to see=20 > how much confusion there really is. I agree it is good for=20 > vendors to=20 > implement similar knobs, but I wonder how much of a problem=20 > there really is. >=20 > Bob >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 15:18:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIRN-0006Yt-K4; Mon, 23 May 2005 15:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIRM-0006Yl-Bx; Mon, 23 May 2005 15:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00574; Mon, 23 May 2005 15:18:15 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIjO-0000y0-Jq; Mon, 23 May 2005 15:36:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 7F95920000D6; Mon, 23 May 2005 15:18:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:18:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 15:18:05 -0400 Message-ID: <936A4045C332714F975800409DE092404A08E1@tayexc14.americas.cpqcorp.net> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVfuy4qRU9Vj5YgQFecJ1BDntB07wAEM1cg From: "Bound, Jim" To: , "Bob Hinden" X-OriginalArrivalTime: 23 May 2005 19:18:07.0399 (UTC) FILETIME=[2682A370:01C55FCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Well stated and with this can we please stop there is no other point to discuss. For those that don't like stateful don't use it. For those that don't like stateless your stuck with it by default set the m and/or o bits. =20 thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Tim Hartrick > Sent: Monday, May 23, 2005 1:09 PM > To: Bob Hinden > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 >=20 >=20 > Bob, >=20 > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > >=20 > > Part of me is starting to think that we might be better off=20 > waiting for=20 > > there to be more operational experience with deployments of=20 > DHCPv6 to see=20 > > how much confusion there really is. I agree it is good for=20 > vendors to=20 > > implement similar knobs, but I wonder how much of a problem=20 > there really is. > >=20 >=20 > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local=20 > decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits=20 > are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What=20 > happens if the M > and/or O bits are set and the client doesn't want to run=20 > DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong=20 > hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an=20 > indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol=20 > specifications.=20 > This is impossible. We should stop trying. >=20 >=20 >=20 >=20 > tim >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 17:17:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKIJ-0003Qg-Dc; Mon, 23 May 2005 17:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKIH-0003QY-Jq; Mon, 23 May 2005 17:17:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21852; Mon, 23 May 2005 17:16:59 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKaK-0001JT-RJ; Mon, 23 May 2005 17:35:41 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4NLFZ306057; Mon, 23 May 2005 14:15:35 -0700 (PDT) Message-Id: <200505232115.j4NLFZ306057@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 23 May 2005 14:15:35 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 4075 on Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4075 Title: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 Author(s): V. Kalusivalingam Status: Standards Track Date: May 2005 Mailbox: vibhaska@cisco.com Pages: 5 Characters: 9424 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-opt-sntp-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4075.txt This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050523141416.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4075 --OtherAccess Content-Type: Message/External-body; name="rfc4075.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050523141416.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Mon May 23 17:19:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKKD-0003jX-6b; Mon, 23 May 2005 17:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKKB-0003jG-AU; Mon, 23 May 2005 17:18:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22124; Mon, 23 May 2005 17:18:57 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKcE-0001OF-F4; Mon, 23 May 2005 17:37:38 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4NLHP307133; Mon, 23 May 2005 14:17:25 -0700 (PDT) Message-Id: <200505232117.j4NLHP307133@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 23 May 2005 14:17:25 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 4076 on Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4076 Title: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s): T. Chown, S. Venaas, A. Vijayabhaskar Status: Informational Date: May 2005 Mailbox: tjc@ecs.soton.ac.uk, venaas@uninett.no, vibhaska@cisco.com Pages: 8 Characters: 15745 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4076.txt IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050523141542.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4076 --OtherAccess Content-Type: Message/External-body; name="rfc4076.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050523141542.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Mon May 23 17:22:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKNq-0004fr-Tr; Mon, 23 May 2005 17:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKNp-0004fg-QA; Mon, 23 May 2005 17:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22875; Mon, 23 May 2005 17:22:43 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKfr-0001n5-O6; Mon, 23 May 2005 17:41:25 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:944:afb5:594e:4c2d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 124C915218; Tue, 24 May 2005 06:25:00 +0900 (JST) Date: Tue, 24 May 2005 06:23:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com In-Reply-To: <1116868160.22946.13.camel@feller> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <1116868160.22946.13.camel@feller> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On 23 May 2005 10:09:20 -0700, >>>>> Tim Hartrick said: >> Part of me is starting to think that we might be better off waiting for >> there to be more operational experience with deployments of DHCPv6 to see >> how much confusion there really is. I agree it is good for vendors to >> implement similar knobs, but I wonder how much of a problem there really is. > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What happens if the M > and/or O bits are set and the client doesn't want to run DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol specifications. > This is impossible. We should stop trying. First of all, as a part of the authors of the "infantile" document, I'd like to emphasize once again that it's not our goal to *enforce* system configuration issues through a protocol document. Perhaps the current text is overacting, but the goal is to "clarify" (as the title of the document shows) confusing points about the M/O flags. (You seem to agree that there *is* confusion, but are saying that clarifying those points is not IETF's work, correct?) Anyway, regarding Bob's point, I can live with that. In fact, my position of these bits has always been we don't have much experience with these flags to be more specific about their usage. And that's why I hesitated to describe more details about those flags in rfc2462bis. On top of this fact, I can live with the approach of leaving the current confusion as is and waiting until we get enough operational experience (then we may or may not need a separate document). Before actually taking this approach, however, I'd like to make a couple of additional notes beforehand: - we removed from rfc2462bis some statements regarding the M/O flags and the "stateful" protocol (=DHCPv6), such as this one: If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. or one even with an RFC2119 keyword: In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating with the intention of clarifying these points in the ipv6-ra-mo-flags document. If we stop this work, it means these statements will simply disappear. - rfc2461bis will also need to remove the last sentence from the description of the M/O flags: M 1-bit "Managed address configuration" flag. When set, it indicates that Dynamic Host Configuration Protocol [DHCPv6] is available for address configuration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is further described in [ADDRCONF]. (this comment already applies regardless of the future of ra-mo-flags, since [ADDRCONF](=rfc2462bis) does not talk about these flags anymore) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 17:57:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKvS-0000yM-Ie; Mon, 23 May 2005 17:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKvN-0000vm-OG; Mon, 23 May 2005 17:57:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00735; Mon, 23 May 2005 17:57:23 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLDR-0004eH-Eq; Mon, 23 May 2005 18:16:05 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DaKvK-0006lb-1r; Mon, 23 May 2005 17:57:22 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 23 May 2005 17:57:22 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: dhc mailing list , dhc chair , Internet Architecture Board , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Vendor-Specific Information Suboption for the DHCP Relay Agent Option' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'Vendor-Specific Information Suboption for the DHCP Relay Agent Option ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. RFC Editor Note Dear RFC Editor, (1) Please change the spelling of IPsec throughout: OLD: IPSEC NEW: IPsec --- (2) At the end of section 3, change: OLD: The Vendor-specific data are of course provider-specific. NEW: The Vendor-specific data are of course vendor-specific. --- (3) Remove the following text: OLD: DHCP server vendors are encouraged to offer their administrators some means of configuring the use of data from incoming Vendor-Specific suboptions in DHCP decision-making. NEW:   - Technical Summary This document defines a suboption for the Dynamic Host Configuration Protocol (DHCP) relay agent information option (RFC 3046). The Vendor-Specific Information suboption allows a DHCP relay agent to include vendor-specific information in DHCP messages it forwards, as configured by its administrator.  The definition of a suboption that carries vendor-specific information allows vendors and network administrators to carry additional information in options that have not been accepted as an Internet Standard.  This relay agent information option suboption is similar to the Vendor Identifying Vendor Option defined in RFC 3925.   - Working Group Summary As noted above, there was no response to the initial last WG on this document.  There was good response and consensus during the second WG last call.   - Protocol Quality This specification is a simple extension of the Vendor Identifying Vendor Option defined in RFC 3925. We have no information about current or planned implementations.  Vendors in the dhc WG expressed support that the new sub-option would be generally useful. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 18:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLTW-0007Wm-4L; Mon, 23 May 2005 18:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLTO-0007VJ-6i; Mon, 23 May 2005 18:32:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05723; Mon, 23 May 2005 18:32:31 -0400 (EDT) From: rfc-editor@rfc-editor.org Received: from council.ci.sugar-land.tx.us ([66.150.129.211] helo=mail.ci.sugar-land.tx.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLlR-0006Pm-74; Mon, 23 May 2005 18:51:13 -0400 Received: from svrpd14 ([192.168.2.137]) by mail.ci.sugar-land.tx.us; Mon, 23 May 2005 17:31:42 -0500 MIME-Version: 1.0 Date: Mon, 23 May 2005 17:31:41 -0500 X-Priority: 3 (Normal) To: ietf-announce@ietf.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org X-Mailer: GWAVA Archive Mailer Content-Type: multipart/mixed; boundary="----=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX" Message-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: Subject: [dhcwg] RFC 4076 on Renumbering Requirements for Stateless Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new Request for Comments is now available in online RFC libraries. RFC 4076 Title: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s): T. Chown, S. Venaas, A. Vijayabhaskar Status: Informational Date: May 2005 Mailbox: tjc@ecs.soton.ac.uk, venaas@uninett.no, vibhaska@cisco.com Pages: 8 Characters: 15745 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4076.txt IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This=20 combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute =2E.. Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: application/octet-stream; name="2#Part.001" Content-Disposition: attachment; filename="2#Part.001" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxNTQyLlJG Q0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDc2DQo= ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: text/plain; name="3#rfc4076.txt" Content-Disposition: attachment; filename="3#rfc4076.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <050523141542.RFC@RFC-EDITOR.ORG> ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: application/octet-stream; name="4#Part.003" Content-Disposition: attachment; filename="4#Part.003" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo= ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: application/octet-stream; name="5#Mime.822" Content-Disposition: attachment; filename="5#Mime.822" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gbWVnYXRyb24uaWV0Zi5vcmcgWzEzMi4xNTEuNi43MV0NCglieSBt YWlsLmNpLnN1Z2FyLWxhbmQudHgudXM7IE1vbiwgMjMgTWF5IDIwMDUgMTY6MjY6NDggLTA1 MDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdC5sb2NhbGRvbWFpbiAoWzEyNy4wLjAuMV0g aGVsbz1tZWdhdHJvbi5pZXRmLm9yZykNCglieSBtZWdhdHJvbi5pZXRmLm9yZyB3aXRoIGVz bXRwIChFeGltIDQuMzIpDQoJaWQgMURhS0tHLTAwMDNqdy1NVjsgTW9uLCAyMyBNYXkgMjAw NSAxNzoxOTowNCAtMDQwMA0KUmVjZWl2ZWQ6IGZyb20gb2Rpbi5pZXRmLm9yZyAoWzEzMi4x NTEuMS4xNzZdIGhlbG89aWV0Zi5vcmcpDQoJYnkgbWVnYXRyb24uaWV0Zi5vcmcgd2l0aCBl c210cCAoRXhpbSA0LjMyKQ0KCWlkIDFEYUtLQi0wMDAzakctQVU7IE1vbiwgMjMgTWF5IDIw MDUgMTc6MTg6NTkgLTA0MDANClJlY2VpdmVkOiBmcm9tIGlldGYtbXguaWV0Zi5vcmcgKGll dGYtbXguaWV0Zi5vcmcgWzEzMi4xNTEuNi4xXSkNCglieSBpZXRmLm9yZyAoOC45LjFhLzgu OS4xYSkgd2l0aCBFU01UUCBpZCBSQUEyMjEyNDsNCglNb24sIDIzIE1heSAyMDA1IDE3OjE4 OjU3IC0wNDAwIChFRFQpDQpSZWNlaXZlZDogZnJvbSBib3JlYXMuaXNpLmVkdSAoWzEyOC45 LjE2MC4xNjFdKQ0KCWJ5IGlldGYtbXguaWV0Zi5vcmcgd2l0aCBlc210cCAoRXhpbSA0LjMz KQ0KCWlkIDFEYUtjRS0wMDAxT0YtRjQ7IE1vbiwgMjMgTWF5IDIwMDUgMTc6Mzc6MzggLTA0 MDANClJlY2VpdmVkOiBmcm9tIElTSS5FRFUgKGFkbWEuaXNpLmVkdSBbMTI4LjkuMTYwLjIz OV0pDQoJYnkgYm9yZWFzLmlzaS5lZHUgKDguMTEuNnAyKzA5MTcvOC4xMS4yKSB3aXRoIEVT TVRQIGlkIGo0TkxIUDMwNzEzMzsNCglNb24sIDIzIE1heSAyMDA1IDE0OjE3OjI1IC0wNzAw IChQRFQpDQpNZXNzYWdlLUlkOiA8MjAwNTA1MjMyMTE3Lmo0TkxIUDMwNzEzM0Bib3JlYXMu aXNpLmVkdT4NClRvOiBpZXRmLWFubm91bmNlQGlldGYub3JnDQpGcm9tOiByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnDQpNaW1lLVZlcnNpb246IDEuMA0KQ29udGVudC1UeXBlOiBNdWx0 aXBhcnQvTWl4ZWQ7IEJvdW5kYXJ5PU5leHRQYXJ0DQpEYXRlOiBNb24sIDIzIE1heSAyMDA1 IDE0OjE3OjI1IC0wNzAwDQpYLUlTSS00LTM5LTYtTWFpbFNjYW5uZXI6IEZvdW5kIHRvIGJl IGNsZWFuDQpYLU1haWxTY2FubmVyLUZyb206IHJmYy1lZEBpc2kuZWR1DQpYLVNwYW0tU2Nv cmU6IC0xNC42ICgtLS0tLS0tLS0tLS0tLSkNClgtU2Nhbi1TaWduYXR1cmU6IGE3ZDJlMzc0 NTFmN2YyMjg0MWUzYjZmNDBjNjdkYjBmDQpDYzogZGhjd2dAaWV0Zi5vcmcsIHJmYy1lZGl0 b3JAcmZjLWVkaXRvci5vcmcNClN1YmplY3Q6IFJGQyA0MDc2IG9uIFJlbnVtYmVyaW5nIFJl cXVpcmVtZW50cyBmb3IgU3RhdGVsZXNzIER5bmFtaWMgSG9zdA0KCUNvbmZpZ3VyYXRpb24g UHJvdG9jb2wgZm9yIElQdjYgKERIQ1B2NikNClgtQmVlblRoZXJlOiBpZXRmLWFubm91bmNl QGlldGYub3JnDQpYLU1haWxtYW4tVmVyc2lvbjogMi4xLjUNClByZWNlZGVuY2U6IGxpc3QN Ckxpc3QtSWQ6IGlldGYtYW5ub3VuY2UuaWV0Zi5vcmcNCkxpc3QtVW5zdWJzY3JpYmU6IDxo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlPiwN Cgk8bWFpbHRvOmlldGYtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXVuc3Vi c2NyaWJlPg0KTGlzdC1Qb3N0OiA8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQpM aXN0LUhlbHA6IDxtYWlsdG86aWV0Zi1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1Ympl Y3Q9aGVscD4NCkxpc3QtU3Vic2NyaWJlOiA8aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZT4sDQoJPG1haWx0bzppZXRmLWFubm91bmNlLXJl cXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+DQpTZW5kZXI6IGlldGYtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZw0KRXJyb3JzLVRvOiBpZXRmLWFubm91bmNlLWJvdW5jZXNA aWV0Zi5vcmcNCg0KDQotLU5leHRQYXJ0DQoNCg0KQSBuZXcgUmVxdWVzdCBmb3IgQ29tbWVu dHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxpbmUgUkZDIGxpYnJhcmllcy4NCg0KDQogICAg ICAgIFJGQyA0MDc2DQoNCiAgICAgICAgVGl0bGU6ICAgICAgUmVudW1iZXJpbmcgUmVxdWly ZW1lbnRzIGZvciBTdGF0ZWxlc3MNCiAgICAgICAgICAgICAgICAgICAgRHluYW1pYyBIb3N0 IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQdjYNCiAgICAgICAgICAgICAgICAgICAg KERIQ1B2NikNCiAgICAgICAgQXV0aG9yKHMpOiAgVC4gQ2hvd24sIFMuIFZlbmFhcywgQS4g VmlqYXlhYmhhc2thcg0KICAgICAgICBTdGF0dXM6ICAgICBJbmZvcm1hdGlvbmFsDQogICAg ICAgIERhdGU6ICAgICAgIE1heSAyMDA1DQogICAgICAgIE1haWxib3g6ICAgIHRqY0BlY3Mu c290b24uYWMudWssIHZlbmFhc0B1bmluZXR0Lm5vLA0KICAgICAgICAgICAgICAgICAgICB2 aWJoYXNrYUBjaXNjby5jb20NCiAgICAgICAgUGFnZXM6ICAgICAgOA0KICAgICAgICBDaGFy YWN0ZXJzOiAxNTc0NQ0KICAgICAgICBVcGRhdGVzL09ic29sZXRlcy9TZWVBbHNvOiAgICBO b25lDQoNCiAgICAgICAgSS1EIFRhZzogICAgZHJhZnQtaWV0Zi1kaGMtc3RhdGVsZXNzLWRo Y3B2Ni1yZW51bWJlcmluZy0wMi50eHQNCg0KICAgICAgICBVUkw6ICAgICAgICBmdHA6Ly9m dHAucmZjLWVkaXRvci5vcmcvaW4tbm90ZXMvcmZjNDA3Ni50eHQNCg0KDQpJUHY2IGhvc3Rz IHVzaW5nIFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uIGFyZSBhYmxlIHRv DQpjb25maWd1cmUgdGhlaXIgSVB2NiBhZGRyZXNzIGFuZCBkZWZhdWx0IHJvdXRlcg0Kc2V0 dGluZ3MgYXV0b21hdGljYWxseS4gIEhvd2V2ZXIsIGZ1cnRoZXIgc2V0dGluZ3MgYXJlIG5v dCBhdmFpbGFibGUuDQpJZiB0aGVzZSBob3N0cyB3aXNoIHRvIGNvbmZpZ3VyZSB0aGVpciBE TlMsIE5UUCwgb3Igb3RoZXINCnNwZWNpZmljIHNldHRpbmdzIGF1dG9tYXRpY2FsbHksIHRo ZSBzdGF0ZWxlc3MgdmFyaWFudCBvZiB0aGUgRHluYW1pYw0KSG9zdCBDb25maWd1cmF0aW9u IFByb3RvY29sIGZvciBJUHY2IChESENQdjYpIGNvdWxkIGJlIHVzZWQuICBUaGlzIA0KY29t YmluYXRpb24gb2YgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gYW5kIHN0 YXRlbGVzcw0KREhDUHY2IGNvdWxkIGJlIHVzZWQgcXVpdGUgY29tbW9ubHkgaW4gSVB2NiBu ZXR3b3Jrcy4gIEhvd2V2ZXIsIGhvc3RzDQp1c2luZyB0aGlzIGNvbWJpbmF0aW9uIGN1cnJl bnRseSBoYXZlIG5vIG1lYW5zIGJ5IHdoaWNoIHRvIGJlDQppbmZvcm1lZCBvZiBjaGFuZ2Vz IGluIHN0YXRlbGVzcyBESENQdjYgb3B0aW9uIHNldHRpbmdzOyBlLmcuLCB0aGUNCmFkZGl0 aW9uIG9mIGEgbmV3IE5UUCBzZXJ2ZXIgYWRkcmVzcywgYSBjaGFuZ2UgaW4gRE5TIHNlYXJj aCBwYXRocywNCm9yIGZ1bGwgc2l0ZSByZW51bWJlcmluZy4gIFRoaXMgZG9jdW1lbnQgaXMg cHJlc2VudGVkIGFzIGEgcHJvYmxlbQ0Kc3RhdGVtZW50IGZyb20gd2hpY2ggYSBzb2x1dGlv biBzaG91bGQgYmUgcHJvcG9zZWQgaW4gYSBzdWJzZXF1ZW50DQpkb2N1bWVudC4NCg0KVGhp cyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhlIER5bmFtaWMgSG9zdCBDb25maWd1cmF0 aW9uIFdvcmtpbmcNCkdyb3VwIG9mIHRoZSBJRVRGLg0KDQpUaGlzIG1lbW8gcHJvdmlkZXMg aW5mb3JtYXRpb24gZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkuICBJdCBkb2VzDQpub3Qg c3BlY2lmeSBhbiBJbnRlcm5ldCBzdGFuZGFyZCBvZiBhbnkga2luZC4gIERpc3RyaWJ1dGlv biBvZiB0aGlzDQptZW1vIGlzIHVubGltaXRlZC4NCg0KVGhpcyBhbm5vdW5jZW1lbnQgaXMg c2VudCB0byB0aGUgSUVURiBsaXN0IGFuZCB0aGUgUkZDLURJU1QgbGlzdC4NClJlcXVlc3Rz IHRvIGJlIGFkZGVkIHRvIG9yIGRlbGV0ZWQgZnJvbSB0aGUgSUVURiBkaXN0cmlidXRpb24g bGlzdA0Kc2hvdWxkIGJlIHNlbnQgdG8gSUVURi1SRVFVRVNUQElFVEYuT1JHLiAgUmVxdWVz dHMgdG8gYmUNCmFkZGVkIHRvIG9yIGRlbGV0ZWQgZnJvbSB0aGUgUkZDLURJU1QgZGlzdHJp YnV0aW9uIGxpc3Qgc2hvdWxkDQpiZSBzZW50IHRvIFJGQy1ESVNULVJFUVVFU1RAUkZDLUVE SVRPUi5PUkcuDQoNCkRldGFpbHMgb24gb2J0YWluaW5nIFJGQ3MgdmlhIEZUUCBvciBFTUFJ TCBtYXkgYmUgb2J0YWluZWQgYnkgc2VuZGluZw0KYW4gRU1BSUwgbWVzc2FnZSB0byByZmMt aW5mb0BSRkMtRURJVE9SLk9SRyB3aXRoIHRoZSBtZXNzYWdlIGJvZHkgDQpoZWxwOiB3YXlz X3RvX2dldF9yZmNzLiAgRm9yIGV4YW1wbGU6DQoNCiAgICAgICAgVG86IHJmYy1pbmZvQFJG Qy1FRElUT1IuT1JHDQogICAgICAgIFN1YmplY3Q6IGdldHRpbmcgcmZjcw0KDQogICAgICAg IGhlbHA6IHdheXNfdG9fZ2V0X3JmY3MNCg0KUmVxdWVzdHMgZm9yIHNwZWNpYWwgZGlzdHJp YnV0aW9uIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gZWl0aGVyIHRoZQ0KYXV0aG9yIG9mIHRo ZSBSRkMgaW4gcXVlc3Rpb24sIG9yIHRvIFJGQy1NYW5hZ2VyQFJGQy1FRElUT1IuT1JHLiAg VW5sZXNzDQpzcGVjaWZpY2FsbHkgbm90ZWQgb3RoZXJ3aXNlIG9uIHRoZSBSRkMgaXRzZWxm LCBhbGwgUkZDcyBhcmUgZm9yDQp1bmxpbWl0ZWQgZGlzdHJpYnV0aW9uLg0KDQpTdWJtaXNz aW9ucyBmb3IgUmVxdWVzdHMgZm9yIENvbW1lbnRzIHNob3VsZCBiZSBzZW50IHRvDQpSRkMt RURJVE9SQFJGQy1FRElUT1IuT1JHLiAgUGxlYXNlIGNvbnN1bHQgUkZDIDIyMjMsIEluc3Ry dWN0aW9ucyB0byBSRkMNCkF1dGhvcnMsIGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uLg0KDQoN CkpveWNlIEsuIFJleW5vbGRzIGFuZCBTYW5keSBHaW5vemENClVTQy9JbmZvcm1hdGlvbiBT Y2llbmNlcyBJbnN0aXR1dGUNCg0KLi4uDQoNCkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdp bGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgTWFpbCBSZWFkZXIgDQppbXBsZW1lbnRhdGlv biB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uDQpvZiB0aGUg UkZDcy4NCg0KLS1OZXh0UGFydA0KQ29udGVudC1UeXBlOiBNdWx0aXBhcnQvQWx0ZXJuYXRp dmU7IEJvdW5kYXJ5PSJPdGhlckFjY2VzcyINCg0KLS1PdGhlckFjY2Vzcw0KQ29udGVudC1U eXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNlcnZlciI7 DQoJc2VydmVyPSJSRkMtSU5GT0BSRkMtRURJVE9SLk9SRyINCg0KQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxNTQyLlJGQ0BSRkMtRURJVE9SLk9S Rz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDc2DQoNCi0tT3RoZXJBY2Nlc3MN CkNvbnRlbnQtVHlwZTogTWVzc2FnZS9FeHRlcm5hbC1ib2R5OyBuYW1lPSJyZmM0MDc2LnR4 dCI7IHNpdGU9ImZ0cC5pc2kuZWR1IjsNCglhY2Nlc3MtdHlwZT0iYW5vbi1mdHAiOyBkaXJl Y3Rvcnk9ImluLW5vdGVzIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQt SUQ6IDwwNTA1MjMxNDE1NDIuUkZDQFJGQy1FRElUT1IuT1JHPg0KDQoNCi0tT3RoZXJBY2Nl c3MtLQ0KLS1OZXh0UGFydA0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1 cy1hc2NpaSINCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiA3Yml0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBpbmxpbmUNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYtQW5ub3VuY2UgbWFpbGlu ZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQoNCi0tTmV4dFBhcnQtLQ0KDQo= ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: text/plain; name="GWAVADAT.TXT" Content-Disposition: attachment; filename="GWAVADAT.TXT" Content-Transfer-Encoding: quoted-printable AdmID:5B57BCF816E1167A066DB9DE189B72B4 ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_282_8243_584e4fe6.ca3ec44e_.MIX-- From dhcwg-bounces@ietf.org Mon May 23 18:32:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLTb-0007YU-SI; Mon, 23 May 2005 18:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLTR-0007W2-3N; Mon, 23 May 2005 18:32:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05733; Mon, 23 May 2005 18:32:34 -0400 (EDT) From: rfc-editor@rfc-editor.org Received: from cityhall.ci.sugar-land.tx.us ([66.150.129.211] helo=mail.ci.sugar-land.tx.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLlU-0006Pn-El; Mon, 23 May 2005 18:51:16 -0400 Received: from svrpd14 ([192.168.2.137]) by mail.ci.sugar-land.tx.us; Mon, 23 May 2005 17:31:43 -0500 MIME-Version: 1.0 Date: Mon, 23 May 2005 17:31:42 -0500 X-Priority: 3 (Normal) To: ietf-announce@ietf.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org X-Mailer: GWAVA Archive Mailer Content-Type: multipart/mixed; boundary="----=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX" Message-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: Subject: [dhcwg] RFC 4075 on Simple Network Time Protocol (SNTP) ConfigurationOption for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new Request for Comments is now available in online RFC libraries. RFC 4075 Title: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 Author(s): V. Kalusivalingam Status: Standards Track Date: May 2005 Mailbox: vibhaska@cisco.com Pages: 5 Characters: 9424 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-opt-sntp-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4075.txt This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute =2E.. Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: application/octet-stream; name="2#Part.001" Content-Disposition: attachment; filename="2#Part.001" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxNDE2LlJG Q0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDc1DQo= ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: text/plain; name="3#rfc4075.txt" Content-Disposition: attachment; filename="3#rfc4075.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <050523141416.RFC@RFC-EDITOR.ORG> ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: application/octet-stream; name="4#Part.003" Content-Disposition: attachment; filename="4#Part.003" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo= ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: application/octet-stream; name="5#Mime.822" Content-Disposition: attachment; filename="5#Mime.822" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gbWVnYXRyb24uaWV0Zi5vcmcgWzEzMi4xNTEuNi43MV0NCglieSBt YWlsLmNpLnN1Z2FyLWxhbmQudHgudXM7IE1vbiwgMjMgTWF5IDIwMDUgMTY6MjI6MjAgLTA1 MDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdC5sb2NhbGRvbWFpbiAoWzEyNy4wLjAuMV0g aGVsbz1tZWdhdHJvbi5pZXRmLm9yZykNCglieSBtZWdhdHJvbi5pZXRmLm9yZyB3aXRoIGVz bXRwIChFeGltIDQuMzIpDQoJaWQgMURhS0lNLTAwMDNSOC0wRzsgTW9uLCAyMyBNYXkgMjAw NSAxNzoxNzowNiAtMDQwMA0KUmVjZWl2ZWQ6IGZyb20gb2Rpbi5pZXRmLm9yZyAoWzEzMi4x NTEuMS4xNzZdIGhlbG89aWV0Zi5vcmcpDQoJYnkgbWVnYXRyb24uaWV0Zi5vcmcgd2l0aCBl c210cCAoRXhpbSA0LjMyKQ0KCWlkIDFEYUtJSC0wMDAzUVktSnE7IE1vbiwgMjMgTWF5IDIw MDUgMTc6MTc6MDIgLTA0MDANClJlY2VpdmVkOiBmcm9tIGlldGYtbXguaWV0Zi5vcmcgKGll dGYtbXguaWV0Zi5vcmcgWzEzMi4xNTEuNi4xXSkNCglieSBpZXRmLm9yZyAoOC45LjFhLzgu OS4xYSkgd2l0aCBFU01UUCBpZCBSQUEyMTg1MjsNCglNb24sIDIzIE1heSAyMDA1IDE3OjE2 OjU5IC0wNDAwIChFRFQpDQpSZWNlaXZlZDogZnJvbSBib3JlYXMuaXNpLmVkdSAoWzEyOC45 LjE2MC4xNjFdKQ0KCWJ5IGlldGYtbXguaWV0Zi5vcmcgd2l0aCBlc210cCAoRXhpbSA0LjMz KQ0KCWlkIDFEYUthSy0wMDAxSlQtUko7IE1vbiwgMjMgTWF5IDIwMDUgMTc6MzU6NDEgLTA0 MDANClJlY2VpdmVkOiBmcm9tIElTSS5FRFUgKGFkbWEuaXNpLmVkdSBbMTI4LjkuMTYwLjIz OV0pDQoJYnkgYm9yZWFzLmlzaS5lZHUgKDguMTEuNnAyKzA5MTcvOC4xMS4yKSB3aXRoIEVT TVRQIGlkIGo0TkxGWjMwNjA1NzsNCglNb24sIDIzIE1heSAyMDA1IDE0OjE1OjM1IC0wNzAw IChQRFQpDQpNZXNzYWdlLUlkOiA8MjAwNTA1MjMyMTE1Lmo0TkxGWjMwNjA1N0Bib3JlYXMu aXNpLmVkdT4NClRvOiBpZXRmLWFubm91bmNlQGlldGYub3JnDQpGcm9tOiByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnDQpNaW1lLVZlcnNpb246IDEuMA0KQ29udGVudC1UeXBlOiBNdWx0 aXBhcnQvTWl4ZWQ7IEJvdW5kYXJ5PU5leHRQYXJ0DQpEYXRlOiBNb24sIDIzIE1heSAyMDA1 IDE0OjE1OjM1IC0wNzAwDQpYLUlTSS00LTM5LTYtTWFpbFNjYW5uZXI6IEZvdW5kIHRvIGJl IGNsZWFuDQpYLU1haWxTY2FubmVyLUZyb206IHJmYy1lZEBpc2kuZWR1DQpYLVNwYW0tU2Nv cmU6IC0xNC42ICgtLS0tLS0tLS0tLS0tLSkNClgtU2Nhbi1TaWduYXR1cmU6IDUwMTFkZjNl MmEyN2FiY2MwNDRlYWExNWJlZmNhYTg3DQpDYzogZGhjd2dAaWV0Zi5vcmcsIHJmYy1lZGl0 b3JAcmZjLWVkaXRvci5vcmcNClN1YmplY3Q6IFJGQyA0MDc1IG9uIFNpbXBsZSBOZXR3b3Jr IFRpbWUgUHJvdG9jb2wgKFNOVFApIENvbmZpZ3VyYXRpb24NCglPcHRpb24gZm9yIERIQ1B2 Ng0KWC1CZWVuVGhlcmU6IGlldGYtYW5ub3VuY2VAaWV0Zi5vcmcNClgtTWFpbG1hbi1WZXJz aW9uOiAyLjEuNQ0KUHJlY2VkZW5jZTogbGlzdA0KTGlzdC1JZDogaWV0Zi1hbm5vdW5jZS5p ZXRmLm9yZw0KTGlzdC1VbnN1YnNjcmliZTogPGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2U+LA0KCTxtYWlsdG86aWV0Zi1hbm5vdW5jZS1y ZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU+DQpMaXN0LVBvc3Q6IDxtYWls dG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCkxpc3QtSGVscDogPG1haWx0bzppZXRmLWFu bm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxwPg0KTGlzdC1TdWJzY3JpYmU6 IDxodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNl PiwNCgk8bWFpbHRvOmlldGYtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXN1 YnNjcmliZT4NClNlbmRlcjogaWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnDQpFcnJv cnMtVG86IGlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZw0KDQoNCi0tTmV4dFBhcnQN Cg0KDQpBIG5ldyBSZXF1ZXN0IGZvciBDb21tZW50cyBpcyBub3cgYXZhaWxhYmxlIGluIG9u bGluZSBSRkMgbGlicmFyaWVzLg0KDQoNCiAgICAgICAgUkZDIDQwNzUNCg0KICAgICAgICBU aXRsZTogICAgICBTaW1wbGUgTmV0d29yayBUaW1lIFByb3RvY29sIChTTlRQKQ0KICAgICAg ICAgICAgICAgICAgICBDb25maWd1cmF0aW9uIE9wdGlvbiBmb3IgREhDUHY2DQogICAgICAg IEF1dGhvcihzKTogIFYuIEthbHVzaXZhbGluZ2FtDQogICAgICAgIFN0YXR1czogICAgIFN0 YW5kYXJkcyBUcmFjaw0KICAgICAgICBEYXRlOiAgICAgICBNYXkgMjAwNQ0KICAgICAgICBN YWlsYm94OiAgICB2aWJoYXNrYUBjaXNjby5jb20NCiAgICAgICAgUGFnZXM6ICAgICAgNQ0K ICAgICAgICBDaGFyYWN0ZXJzOiA5NDI0DQogICAgICAgIFVwZGF0ZXMvT2Jzb2xldGVzL1Nl ZUFsc286ICAgIE5vbmUNCg0KICAgICAgICBJLUQgVGFnOiAgICBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtb3B0LXNudHAtMDEudHh0DQoNCiAgICAgICAgVVJMOiAgICAgICAgZnRwOi8vZnRw LnJmYy1lZGl0b3Iub3JnL2luLW5vdGVzL3JmYzQwNzUudHh0DQoNCg0KVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBuZXcgREhDUHY2IG9wdGlvbiBmb3IgcGFzc2luZyBhIGxpc3Qgb2YN ClNpbXBsZSBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKFNOVFApIHNlcnZlciBhZGRyZXNzZXMg dG8gYSBjbGllbnQuDQoNClRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBEeW5h bWljIEhvc3QgQ29uZmlndXJhdGlvbiBXb3JraW5nDQpHcm91cCBvZiB0aGUgSUVURi4NCg0K VGhpcyBpcyBub3cgYSBQcm9wb3NlZCBTdGFuZGFyZCBQcm90b2NvbC4NCg0KVGhpcyBkb2N1 bWVudCBzcGVjaWZpZXMgYW4gSW50ZXJuZXQgc3RhbmRhcmRzIHRyYWNrIHByb3RvY29sIGZv cg0KdGhlIEludGVybmV0IGNvbW11bml0eSwgYW5kIHJlcXVlc3RzIGRpc2N1c3Npb24gYW5k IHN1Z2dlc3Rpb25zDQpmb3IgaW1wcm92ZW1lbnRzLiAgUGxlYXNlIHJlZmVyIHRvIHRoZSBj dXJyZW50IGVkaXRpb24gb2YgdGhlDQoiSW50ZXJuZXQgT2ZmaWNpYWwgUHJvdG9jb2wgU3Rh bmRhcmRzIiAoU1REIDEpIGZvciB0aGUNCnN0YW5kYXJkaXphdGlvbiBzdGF0ZSBhbmQgc3Rh dHVzIG9mIHRoaXMgcHJvdG9jb2wuICBEaXN0cmlidXRpb24NCm9mIHRoaXMgbWVtbyBpcyB1 bmxpbWl0ZWQuDQoNClRoaXMgYW5ub3VuY2VtZW50IGlzIHNlbnQgdG8gdGhlIElFVEYgbGlz dCBhbmQgdGhlIFJGQy1ESVNUIGxpc3QuDQpSZXF1ZXN0cyB0byBiZSBhZGRlZCB0byBvciBk ZWxldGVkIGZyb20gdGhlIElFVEYgZGlzdHJpYnV0aW9uIGxpc3QNCnNob3VsZCBiZSBzZW50 IHRvIElFVEYtUkVRVUVTVEBJRVRGLk9SRy4gIFJlcXVlc3RzIHRvIGJlDQphZGRlZCB0byBv ciBkZWxldGVkIGZyb20gdGhlIFJGQy1ESVNUIGRpc3RyaWJ1dGlvbiBsaXN0IHNob3VsZA0K YmUgc2VudCB0byBSRkMtRElTVC1SRVFVRVNUQFJGQy1FRElUT1IuT1JHLg0KDQpEZXRhaWxz IG9uIG9idGFpbmluZyBSRkNzIHZpYSBGVFAgb3IgRU1BSUwgbWF5IGJlIG9idGFpbmVkIGJ5 IHNlbmRpbmcNCmFuIEVNQUlMIG1lc3NhZ2UgdG8gcmZjLWluZm9AUkZDLUVESVRPUi5PUkcg d2l0aCB0aGUgbWVzc2FnZSBib2R5IA0KaGVscDogd2F5c190b19nZXRfcmZjcy4gIEZvciBl eGFtcGxlOg0KDQogICAgICAgIFRvOiByZmMtaW5mb0BSRkMtRURJVE9SLk9SRw0KICAgICAg ICBTdWJqZWN0OiBnZXR0aW5nIHJmY3MNCg0KICAgICAgICBoZWxwOiB3YXlzX3RvX2dldF9y ZmNzDQoNClJlcXVlc3RzIGZvciBzcGVjaWFsIGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUgYWRk cmVzc2VkIHRvIGVpdGhlciB0aGUNCmF1dGhvciBvZiB0aGUgUkZDIGluIHF1ZXN0aW9uLCBv ciB0byBSRkMtTWFuYWdlckBSRkMtRURJVE9SLk9SRy4gIFVubGVzcw0Kc3BlY2lmaWNhbGx5 IG5vdGVkIG90aGVyd2lzZSBvbiB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3MgYXJlIGZvcg0K dW5saW1pdGVkIGRpc3RyaWJ1dGlvbi4NCg0KU3VibWlzc2lvbnMgZm9yIFJlcXVlc3RzIGZv ciBDb21tZW50cyBzaG91bGQgYmUgc2VudCB0bw0KUkZDLUVESVRPUkBSRkMtRURJVE9SLk9S Ry4gIFBsZWFzZSBjb25zdWx0IFJGQyAyMjIzLCBJbnN0cnVjdGlvbnMgdG8gUkZDDQpBdXRo b3JzLCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbi4NCg0KDQpKb3ljZSBLLiBSZXlub2xkcyBh bmQgU2FuZHkgR2lub3phDQpVU0MvSW5mb3JtYXRpb24gU2NpZW5jZXMgSW5zdGl0dXRlDQoN Ci4uLg0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29t cGxpYW50IE1haWwgUmVhZGVyIA0KaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSBy ZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbg0Kb2YgdGhlIFJGQ3MuDQoNCi0tTmV4dFBhcnQN CkNvbnRlbnQtVHlwZTogTXVsdGlwYXJ0L0FsdGVybmF0aXZlOyBCb3VuZGFyeT0iT3RoZXJB Y2Nlc3MiDQoNCi0tT3RoZXJBY2Nlc3MNCkNvbnRlbnQtVHlwZTogTWVzc2FnZS9FeHRlcm5h bC1ib2R5OyBhY2Nlc3MtdHlwZT0ibWFpbC1zZXJ2ZXIiOw0KCXNlcnZlcj0iUkZDLUlORk9A UkZDLUVESVRPUi5PUkciDQoNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbg0KQ29udGVudC1J RDogPDA1MDUyMzE0MTQxNi5SRkNAUkZDLUVESVRPUi5PUkc+DQoNClJFVFJJRVZFOiByZmMN CkRPQy1JRDogcmZjNDA3NQ0KDQotLU90aGVyQWNjZXNzDQpDb250ZW50LVR5cGU6IE1lc3Nh Z2UvRXh0ZXJuYWwtYm9keTsgbmFtZT0icmZjNDA3NS50eHQiOyBzaXRlPSJmdHAuaXNpLmVk dSI7DQoJYWNjZXNzLXR5cGU9ImFub24tZnRwIjsgZGlyZWN0b3J5PSJpbi1ub3RlcyINCg0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxNDE2LlJG Q0BSRkMtRURJVE9SLk9SRz4NCg0KDQotLU90aGVyQWNjZXNzLS0NCi0tTmV4dFBhcnQNCkNv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQpNSU1FLVZlcnNp b246IDEuMA0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdA0KQ29udGVudC1EaXNw b3NpdGlvbjogaW5saW5lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJRVRGLUFubm91bmNlIG1haWxpbmcgbGlzdA0KSUVURi1Bbm5vdW5j ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0 Zi1hbm5vdW5jZQ0KDQotLU5leHRQYXJ0LS0NCg0K ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: text/plain; name="GWAVADAT.TXT" Content-Disposition: attachment; filename="GWAVADAT.TXT" Content-Transfer-Encoding: quoted-printable AdmID:A18E27C8162576E910696554A4B554DC ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_ff1_6426_b4fd4bd8.311414b5_.MIX-- From dhcwg-bounces@ietf.org Mon May 23 18:42:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLcf-00016P-F3; Mon, 23 May 2005 18:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLcd-00012p-KO; Mon, 23 May 2005 18:42:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07372; Mon, 23 May 2005 18:42:04 -0400 (EDT) Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLuh-00072y-59; Mon, 23 May 2005 19:00:47 -0400 Received: from alerion.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id j4NMftp22349; Mon, 23 May 2005 15:41:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id 8EE763F0021; Mon, 23 May 2005 15:41:55 -0700 (PDT) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21114-03; Mon, 23 May 2005 15:41:54 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id 77B573F0020; Mon, 23 May 2005 15:41:54 -0700 (PDT) From: Tim Hartrick To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: <57482c02880cda3a9a5e541bb72ca6fc@message.md5> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <1116868160.22946.13.camel@feller> <57482c02880cda3a9a5e541bb72ca6fc@message.md5> Content-Type: text/plain; charset=UTF-8 Organization: Mentat Inc. Message-Id: <1116887762.22946.43.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 May 2005 15:36:02 -0700 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roll.mentat.com id j4NMftp22349 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@mentat.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Jinmei, On Mon, 2005-05-23 at 14:23, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: >=20 > > More than part of me is thinking this. It seems to me that there is = a > > continuing confusion about how these bits interact with local decisio= ns > > by the administrator of a specific machine or network. People are > > asking questions like "What happens if the M and/or O bits are clear = but > > there is a DHCP server?" or "What happens if the M and/or O bits are > > clear but the client wants to use DHCP anyway" or "What happens if th= e M > > and/or O bits are set and the client doesn't want to run DHCP". None= of > > these questions are in the realm of protocol design. Clearly, local > > administrators will do as they please with their machines. In this > > respect the M and O bits have never been anything but strong hints as= to > > what the client should do. The client is always free to ignore the > > hints. Further network administrators are free to misconfigure their > > networks as they please. The current text describing these bits is > > clear almost to the point of being infantile. This isn't an indictme= nt > > of the authors. Rather it is an indictment of attempts to enforce > > system configuration and management rules via protocol specifications= .=20 > > This is impossible. We should stop trying. >=20 > First of all, as a part of the authors of the "infantile" document, > I'd like to emphasize once again that it's not our goal to *enforce* > system configuration issues through a protocol document. Perhaps the > current text is overacting, but the goal is to "clarify" (as the title > of the document shows) confusing points about the M/O flags. (You > seem to agree that there *is* confusion, but are saying that > clarifying those points is not IETF's work, correct?) >=20 I made it clear that the current text is, I believe, a reaction on the authors' part to the persistent attempts to place operational restrictions on this protocol mechanism from within the specification.=20 The clarity is good. I am for clarity. I apologize for any offense.=20 However, I am against continuing to modify the document and the protocol in the hopes that the questions cited above will cease. They won't because they have nothing to do with the protocol. They have to do with operators wanting to tell users how to use their machines and users not wanting to do what operators want them to do and how that tension gets sorted out by what features and knobs are included or not included in the implementations the operators and users purchase. We aren't writing product specifications here. Trying to specify every implementation knob in the protocol specification is a mistake and removing useful features because all the possible knobs to control it aren't specified is also a mistake. tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 23 21:28:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaOE2-0007is-4e; Mon, 23 May 2005 21:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaODy-0007ic-Ju; Mon, 23 May 2005 21:28:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20937; Mon, 23 May 2005 21:28:48 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaOW3-0004rH-FJ; Mon, 23 May 2005 21:47:31 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGZ006I703EDO@mailout1.samsung.com>; Tue, 24 May 2005 10:28:26 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IGZ0072T03E36@mmp1.samsung.com>; Tue, 24 May 2005 10:28:26 +0900 (KST) Date: Tue, 24 May 2005 10:28:22 +0900 From: "Soohong Daniel Park@SAMSUNG.COM" In-reply-to: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> To: "'Thomas Narten'" , ipv6@ietf.org Message-id: <019201c55fff$df84d1d0$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org Subject: [dhcwg] RE: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (Sorry for being too late response) I am really not sure why this thread is moved to *meta thought*. When I wrote this document, I originally thought this task was our explicit consensus to be a seperated document from 2462bis. Am I missing anything ? I don't think so. See below link (October 2004) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03799.html It would have been nice if you said your comment at that time. As you mentiond, simplicity is also good aspect and we (all author) was trying to make this document as simple as we can. If we feel it so heavy, we will make it more concise than now. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Saturday, May 21, 2005 2:24 AM > To: ipv6@ietf.org > Subject: meta thoughts on m/o bits > > > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... > > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. > > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. > > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. > > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. > > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. > > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. > > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. > > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. > > Remember, simplicity is Good! > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 10:46:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daafn-0001Eq-4Y; Tue, 24 May 2005 10:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daafk-0001EE-K3; Tue, 24 May 2005 10:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06172; Tue, 24 May 2005 10:46:18 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daaxw-0005qP-6O; Tue, 24 May 2005 11:05:09 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEk8gi007137; Tue, 24 May 2005 10:46:08 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEk7Lu144284; Tue, 24 May 2005 10:46:07 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEk77U000444; Tue, 24 May 2005 10:46:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEk7rx000404; Tue, 24 May 2005 10:46:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4OEk6WR025434; Tue, 24 May 2005 10:46:06 -0400 Message-Id: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Sat, 14 May 2005 17:35:37 +0900." Date: Tue, 24 May 2005 10:46:06 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: dhcwg@ietf.org, IPv6 WG Subject: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt ] X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > If we respect both the original sense of RFC2462 and our consensus > about the semantics separation of the M/O flags, I believe the right > solution is the following: I think we should be careful NOT to get hung up on what the original intent of the M/O bits were, but focus on what the right behavior should be, given what we know now/today, and given the DHC protocols we actually have. The M/O bits were defined before we had DHCPv6 specified. I'd argue that the M/O bits are a classic example of defining protocol/bits before we really had a clear understanding of how they would be used, what the semantics should be or what the actual protocols would be that get invoked as a result of those bits. Surprise, surprise, when one invents protocols/mechanisms in such cases, we often get the details wrong. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 10:53:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaamQ-0002Ok-AU; Tue, 24 May 2005 10:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaamN-0002OZ-S7 for dhcwg@megatron.ietf.org; Tue, 24 May 2005 10:53:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06934 for ; Tue, 24 May 2005 10:53:09 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dab4Y-00069J-EI for dhcwg@ietf.org; Tue, 24 May 2005 11:12:00 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEr0KK000349 for ; Tue, 24 May 2005 10:53:00 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEr0LN111606 for ; Tue, 24 May 2005 10:53:00 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEqxxM005783 for ; Tue, 24 May 2005 10:53:00 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEqxnL005774 for ; Tue, 24 May 2005 10:52:59 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4OEqx5X025495 for ; Tue, 24 May 2005 10:52:59 -0400 Message-Id: <200505241452.j4OEqx5X025495@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Tue, 24 May 2005 10:52:59 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [dhcwg] purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dhcwg@ietf.org, ipv6@ietf.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Oops, should have sent this to both lists... Thomas ------- Forwarded Message From: Thomas Narten To: ipv6@ietf.org Date: Tue, 24 May 2005 10:45:19 -0400 Subject: purpose of m/o bit I wonder if there is key question here that the community has simply not agreed on (yet), and that that question is at the heart of all this "confusion". Does the community feel that operators need RA bits that control/indicate whether a client is to invoke DHC? That is, is there a need for the sys admin to signal to client whether DHC is to be invoked? Second, is it important that such a signal be honored by clients? (That is, if clients end up mostly ignoring the flags, does their presence become useless?) For example, should the sys admin be able to say "do not run DHC, doing so wastes local resources and won't get you any config info"? (And should that be honored by clients?) Fundamentally, it is only the access network that has knowledge of whether running DHC is useful. Thus, by default, clients (arguably) can't know whether running DHC is useful, so by default they shold invoke DHC (unless the sys admin signals "don't invoke DHC"). Or (switching the argument), by default, client should not invoke DHC, unless the local sys admin indicates doing so is appropriate. If we can't agree that the above is necessary (i.e., is a "problem statement" of sorts), I really have to wonder what purpose the R/A bits can serve or whether we will ever have a shared understanding of what they are supposed to do. Having them be a hint (that clients in practice ignore half the time) would seem to solve no useful purpose (IMO) and would provide the sys admin with useless tools (since clients wouldn't respond to the usage of the tool in predicatable ways). The result would simply be more confusion. (Oh, that is already the state we are in!!! :-)) So, what is it? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 11:12:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab57-0007Ge-PG; Tue, 24 May 2005 11:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab55-0007GT-IX; Tue, 24 May 2005 11:12:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09045; Tue, 24 May 2005 11:12:29 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DabNI-000746-30; Tue, 24 May 2005 11:31:20 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel12.hp.com (Postfix) with ESMTP id 8A439411437; Tue, 24 May 2005 08:12:27 -0700 (PDT) Received: from cacexb11.americas.cpqcorp.net ([16.92.1.48]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 08:12:27 -0700 Received: from tayexb11.americas.cpqcorp.net ([16.103.130.93]) by cacexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 08:12:27 -0700 Received: from tayexg11.americas.cpqcorp.net ([16.103.130.186]) by tayexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 11:12:01 -0400 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 11:08:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG LastCall:draft-ietf-ipv6-ra-mo-flags-01.txt ] Date: Tue, 24 May 2005 11:08:11 -0400 Message-ID: <936A4045C332714F975800409DE092404A0B85@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG LastCall:draft-ietf-ipv6-ra-mo-flags-01.txt ] Thread-Index: AcVgcDTTKGIO+UcnQgSPQoa3waPMcgAAfocQ From: "Bound, Jim" To: "Thomas Narten" , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-OriginalArrivalTime: 24 May 2005 15:08:12.0766 (UTC) FILETIME=[676CF7E0:01C56072] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thomas, With respect. When we defined M and O we were assuming a stateful support system. Thus we did the right thing. I was there as you. Those that are in denial that stateful is as important to the business and market deployment of IPv6 are simply missing the point. In addition, and I think we agree on this point, it is not the IETFs business to tell the market what or how to deploy. /jim > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Thomas Narten > Sent: Tuesday, May 24, 2005 10:46 AM > To: JINMEI Tatuya / $B?@L@C#:H(J > Cc: dhcwg@ietf.org; IPv6 WG > Subject: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG > LastCall:draft-ietf-ipv6-ra-mo-flags-01.txt ] > > JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > writes: > > > If we respect both the original sense of RFC2462 and our consensus > > about the semantics separation of the M/O flags, I believe the right > > solution is the following: > > I think we should be careful NOT to get hung up on what the original > intent of the M/O bits were, but focus on what the right behavior > should be, given what we know now/today, and given the DHC protocols > we actually have. > > The M/O bits were defined before we had DHCPv6 specified. I'd argue > that the M/O bits are a classic example of defining protocol/bits > before we really had a clear understanding of how they would be used, > what the semantics should be or what the actual protocols would be > that get invoked as a result of those bits. > > Surprise, surprise, when one invents protocols/mechanisms in such > cases, we often get the details wrong. > > Thomas > > _______________________________________________ > 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-bounces@ietf.org Tue May 24 11:35:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabRm-00048i-Tj; Tue, 24 May 2005 11:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabRk-00048a-Fh; Tue, 24 May 2005 11:35:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11488; Tue, 24 May 2005 11:35:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dabjx-00082I-Cl; Tue, 24 May 2005 11:54:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 May 2005 11:35:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4OFZS5C021409; Tue, 24 May 2005 11:35:44 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 11:35:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 11:35:41 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> Thread-Topic: purpose of m/o bit Thread-Index: AcVgb25TwdwI/HyIQyGACsRQNut72QAAzvNQAABTVGA= From: "Bernie Volz \(volz\)" To: "Bound, Jim" , "Thomas Narten" , , X-OriginalArrivalTime: 24 May 2005 15:35:42.0754 (UTC) FILETIME=[3EE52820:01C56076] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thomas/Jim: I believe that most of us are in agreement on the main points -- the bit(s) are useful and SHOULD be acted on by clients accordingly. I believe were there are issues are in the details about what each bit means and how they interact and what happens if they're not set correctly. Personally I think the last issue should be a non-issue since there are plenty of other parameters that need to be set correctly for networks to run. At worst, this causes clients not to get addresses (which will likely generate complaints to the network administrators fairly quickly) or wastes bandwidth. If we assume that current bits are retained, there is a problem if both the M and O bits are set with what a client should do if it supports both stateful and stateless DHCPv6 but fails to receive responses to Solicit requests. If the client only supports stateless DHCPv6, there is no issue since it just sends Information-Request messages. But if the client supports both (really this means it is a "full" 3315 client), does it do both in parallel, initiate stateful (Solicits) and failover to stateless at some point (and does it continue to do stateful in the background), or? These areas that are not well documented in the DHCPv6 specifications (3315 + 3736) and we need to clarify. We've discussed several proposals but I don't think we've closed that discussion. Having one bit instead of two doesn't really solve this problem since there is still the question of what a "full" 3315 client does when it fails to receive a response to Solicits or receives advertises that no addresses are available.=20 Though having one bit (saying run DHCPv6) does help as it simplifies the problem about what M=3D1 and O=3D0 means. Thus, I would suggest we: - Have one bit that says "run DHCPv6". If the client is stateful, it does "full" 3315". If the client is stateless (3736), it does stateless only. - Have the DHC WG publish a draft to properly define the behavior of clients (and servers) when stateful service is not available and only stateless is available. IE, when should a client switch to using Information-Request or should all servers support Solicit and should an Advertise be able to carry "other configuration" options when addresses are not available. (Or perhaps there are other options to be considered.) - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bound, Jim > Sent: Tuesday, May 24, 2005 11:13 AM > To: Thomas Narten; ipv6@ietf.org > Subject: RE: purpose of m/o bit >=20 > =20 > > Does the community feel that operators need RA bits that > > control/indicate whether a client is to invoke DHC? That=20 > is, is there > > a need for the sys admin to signal to client whether DHC is to be > > invoked? >=20 > yes. >=20 > >=20 > > Second, is it important that such a signal be honored by clients? > > (That is, if clients end up mostly ignoring the flags, does their > > presence become useless?) >=20 > That is not our business but yes I believe the market and clients will > honor them as requirement from the organizations policy using stateful > or other config info. >=20 > >=20 > > For example, should the sys admin be able to say "do not run DHC, > > doing so wastes local resources and won't get you any config info"? > > (And should that be honored by clients?) >=20 > Sure just don't set the current bits in RAs. >=20 > >=20 > > Fundamentally, it is only the access network that has knowledge of > > whether running DHC is useful. Thus, by default, clients (arguably) > > can't know whether running DHC is useful, so by default they shold > > invoke DHC (unless the sys admin signals "don't invoke DHC"). >=20 > I think the m or o bit will be the decision policy point.=20 >=20 > >=20 > > Or (switching the argument), by default, client should not=20 > invoke DHC, > > unless the local sys admin indicates doing so is appropriate. >=20 > Corrrect same as question above. >=20 > >=20 > > If we can't agree that the above is necessary (i.e., is a "problem > > statement" of sorts), I really have to wonder what purpose the R/A > > bits can serve or whether we will ever have a shared=20 > understanding of > > what they are supposed to do. Having them be a hint (that clients in > > practice ignore half the time) would seem to solve no useful purpose > > (IMO) and would provide the sys admin with useless tools (since > > clients wouldn't respond to the usage of the tool in predicatable > > ways). The result would simply be more confusion. (Oh, that=20 > is already > > the state we are in!!! :-)) >=20 > We agreed on this years ago. >=20 > /jim > >=20 > > So, what is it?=20 > >=20 > > Thomas > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 12:18:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dac7G-0005LY-Lv; Tue, 24 May 2005 12:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dac7C-0005LQ-Uz; Tue, 24 May 2005 12:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15447; Tue, 24 May 2005 12:18:44 -0400 (EDT) Received: from tayrelbas02.tay.hp.com ([161.114.80.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DacPP-0001eF-SV; Tue, 24 May 2005 12:37:36 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas02.tay.hp.com (Postfix) with ESMTP id 8DDC515D; Tue, 24 May 2005 12:11:52 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 12:10:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 12:10:56 -0400 Message-ID: <936A4045C332714F975800409DE092404A0BF8@tayexc14.americas.cpqcorp.net> Thread-Topic: purpose of m/o bit Thread-Index: AcVgb25TwdwI/HyIQyGACsRQNut72QAAzvNQAABTVGAAAcXpAA== From: "Bound, Jim" To: "Bernie Volz (volz)" , "Thomas Narten" , , X-OriginalArrivalTime: 24 May 2005 16:10:59.0114 (UTC) FILETIME=[2C5810A0:01C5607B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie, I think your honing down to valid points. I view m bit set implying o bit use too. but that is not stated. =20 /jim=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Tuesday, May 24, 2005 11:36 AM > To: Bound, Jim; Thomas Narten; ipv6@ietf.org; dhcwg@ietf.org > Subject: RE: purpose of m/o bit >=20 > Thomas/Jim: >=20 > I believe that most of us are in agreement on the main points -- the > bit(s) are useful and SHOULD be acted on by clients accordingly. >=20 > I believe were there are issues are in the details about what each bit > means and how they interact and what happens if they're not set > correctly. >=20 > Personally I think the last issue should be a non-issue since=20 > there are > plenty of other parameters that need to be set correctly for=20 > networks to > run. At worst, this causes clients not to get addresses (which will > likely generate complaints to the network administrators=20 > fairly quickly) > or wastes bandwidth. >=20 > If we assume that current bits are retained, there is a=20 > problem if both > the M and O bits are set with what a client should do if it supports > both stateful and stateless DHCPv6 but fails to receive responses to > Solicit requests. >=20 > If the client only supports stateless DHCPv6, there is no=20 > issue since it > just sends Information-Request messages. >=20 > But if the client supports both (really this means it is a "full" 3315 > client), does it do both in parallel, initiate stateful (Solicits) and > failover to stateless at some point (and does it continue to=20 > do stateful > in the background), or? These areas that are not well=20 > documented in the > DHCPv6 specifications (3315 + 3736) and we need to clarify. We've > discussed several proposals but I don't think we've closed that > discussion. >=20 > Having one bit instead of two doesn't really solve this problem since > there is still the question of what a "full" 3315 client does when it > fails to receive a response to Solicits or receives advertises that no > addresses are available.=20 >=20 > Though having one bit (saying run DHCPv6) does help as it=20 > simplifies the > problem about what M=3D1 and O=3D0 means. >=20 > Thus, I would suggest we: > - Have one bit that says "run DHCPv6". If the client is stateful, it > does "full" 3315". If the client is stateless (3736), it does=20 > stateless > only. > - Have the DHC WG publish a draft to properly define the behavior of > clients (and servers) when stateful service is not available and only > stateless is available. IE, when should a client switch to using > Information-Request or should all servers support Solicit and=20 > should an > Advertise be able to carry "other configuration" options when=20 > addresses > are not available. (Or perhaps there are other options to be > considered.) >=20 > - Bernie >=20 >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > Behalf Of Bound, Jim > > Sent: Tuesday, May 24, 2005 11:13 AM > > To: Thomas Narten; ipv6@ietf.org > > Subject: RE: purpose of m/o bit > >=20 > > =20 > > > Does the community feel that operators need RA bits that > > > control/indicate whether a client is to invoke DHC? That=20 > > is, is there > > > a need for the sys admin to signal to client whether DHC is to be > > > invoked? > >=20 > > yes. > >=20 > > >=20 > > > Second, is it important that such a signal be honored by clients? > > > (That is, if clients end up mostly ignoring the flags, does their > > > presence become useless?) > >=20 > > That is not our business but yes I believe the market and=20 > clients will > > honor them as requirement from the organizations policy=20 > using stateful > > or other config info. > >=20 > > >=20 > > > For example, should the sys admin be able to say "do not run DHC, > > > doing so wastes local resources and won't get you any=20 > config info"? > > > (And should that be honored by clients?) > >=20 > > Sure just don't set the current bits in RAs. > >=20 > > >=20 > > > Fundamentally, it is only the access network that has knowledge of > > > whether running DHC is useful. Thus, by default, clients=20 > (arguably) > > > can't know whether running DHC is useful, so by default they shold > > > invoke DHC (unless the sys admin signals "don't invoke DHC"). > >=20 > > I think the m or o bit will be the decision policy point.=20 > >=20 > > >=20 > > > Or (switching the argument), by default, client should not=20 > > invoke DHC, > > > unless the local sys admin indicates doing so is appropriate. > >=20 > > Corrrect same as question above. > >=20 > > >=20 > > > If we can't agree that the above is necessary (i.e., is a "problem > > > statement" of sorts), I really have to wonder what purpose the R/A > > > bits can serve or whether we will ever have a shared=20 > > understanding of > > > what they are supposed to do. Having them be a hint (that=20 > clients in > > > practice ignore half the time) would seem to solve no=20 > useful purpose > > > (IMO) and would provide the sys admin with useless tools (since > > > clients wouldn't respond to the usage of the tool in predicatable > > > ways). The result would simply be more confusion. (Oh, that=20 > > is already > > > the state we are in!!! :-)) > >=20 > > We agreed on this years ago. > >=20 > > /jim > > >=20 > > > So, what is it?=20 > > >=20 > > > Thomas > > >=20 > > >=20 > > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=20 > -------------------------------------------------------------------- > > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 21:46:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DakyM-0004dA-8A; Tue, 24 May 2005 21:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DakyI-0004bo-0n; Tue, 24 May 2005 21:46:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15336; Tue, 24 May 2005 21:46:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DalGa-0002Kw-An; Tue, 24 May 2005 22:05:04 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:74c5:e655:7a58:c31b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7544B15218; Wed, 25 May 2005 10:48:41 +0900 (JST) Date: Wed, 25 May 2005 10:47:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> References: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dhcwg@ietf.org, IPv6 WG Subject: [dhcwg] Re: Original intent of M/O bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 May 2005 10:46:06 -0400, >>>>> Thomas Narten said: >> If we respect both the original sense of RFC2462 and our consensus >> about the semantics separation of the M/O flags, I believe the right >> solution is the following: > I think we should be careful NOT to get hung up on what the original > intent of the M/O bits were, but focus on what the right behavior > should be, given what we know now/today, and given the DHC protocols > we actually have. In general, I agree (if I sound self-conflicting, note the "If" in the cited part above). In practice, however, it should also be noted that one major push back argument in the similar discussion for rfc2462bis a year ago was that we should not introduce incompatible changes to existing implementations that assume the "original intent". It seems to me that this is a typical case of tradeoff between "it's never too late to do the right thing" vs "don't break compatibility". In the previous discussion, the latter was preferred, and so we are here. If we can now prefer the former argument, I'm personally willing to take it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 22:08:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DalKA-0000XT-9i; Tue, 24 May 2005 22:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DalK5-0000XK-Un; Tue, 24 May 2005 22:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16405; Tue, 24 May 2005 22:08:39 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DalcO-0002m7-6e; Tue, 24 May 2005 22:27:36 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:74c5:e655:7a58:c31b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B348015218; Wed, 25 May 2005 11:11:12 +0900 (JST) Date: Wed, 25 May 2005 11:09:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Thomas Narten , dhcwg@ietf.org, ipv6@ietf.org, "Bound, Jim" Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 May 2005 11:35:41 -0400, >>>>> "Bernie Volz (volz)" said: > I believe were there are issues are in the details about what each bit > means and how they interact and what happens if they're not set > correctly. > Personally I think the last issue should be a non-issue since there are > plenty of other parameters that need to be set correctly for networks to > run. At worst, this causes clients not to get addresses (which will > likely generate complaints to the network administrators fairly quickly) > or wastes bandwidth. I agree. While I have repeatedly mentioned the latter case, I actually don't care about the case where a client cannot get addresses via DHCP due to incorrect M/O flags and/or misconfigured DHCPv6 servers. In this case, the user can do nothing but complain to the administrator. I'm more concerned about the case you mentioned in the succeeding lines (below), and it looks we are in some level of agreement. > If we assume that current bits are retained, there is a problem if both > the M and O bits are set with what a client should do if it supports > both stateful and stateless DHCPv6 but fails to receive responses to > Solicit requests. > If the client only supports stateless DHCPv6, there is no issue since it > just sends Information-Request messages. > But if the client supports both (really this means it is a "full" 3315 > client), does it do both in parallel, initiate stateful (Solicits) and > failover to stateless at some point (and does it continue to do stateful > in the background), or? These areas that are not well documented in the > DHCPv6 specifications (3315 + 3736) and we need to clarify. We've > discussed several proposals but I don't think we've closed that > discussion. Exactly. This is one of my major concerns, which I've been trying to address through the mo-flags draft with my co-authors (although we may not have been convincing enough in that work so far). > Thus, I would suggest we: > - Have one bit that says "run DHCPv6". If the client is stateful, it > does "full" 3315". If the client is stateless (3736), it does stateless > only. > - Have the DHC WG publish a draft to properly define the behavior of > clients (and servers) when stateful service is not available and only > stateless is available. IE, when should a client switch to using > Information-Request or should all servers support Solicit and should an > Advertise be able to carry "other configuration" options when addresses > are not available. (Or perhaps there are other options to be > considered.) If we can get the DHC draft soon (it's okay even if it's just an I-D), I think this is a reasonable approach. But since this (the first bullet more specifically) clearly results in a "backward-incompatible" change, we'll need a meta-level agreement for this approach. (In particular, we should consider how this affects the rfc2461bis work as an urgent issue) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 23:15:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamMm-0002eA-Qi; Tue, 24 May 2005 23:15:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamMi-0002e2-LH; Tue, 24 May 2005 23:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19734; Tue, 24 May 2005 23:15:25 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Damez-0004UG-CS; Tue, 24 May 2005 23:34:23 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH000DHGZPEGS@mailout3.samsung.com>; Wed, 25 May 2005 12:15:14 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH000I6TZPEPI@mmp2.samsung.com>; Wed, 25 May 2005 12:15:14 +0900 (KST) Date: Wed, 25 May 2005 12:15:10 +0900 From: "Soohong Daniel Park@samsung.com" In-reply-to: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz (volz)'" , "'Bound, Jim'" , "'Thomas Narten'" , ipv6@ietf.org, dhcwg@ietf.org Message-id: <010701c560d7$f5ad2f10$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Cc: Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > But if the client supports both (really this means it is a "full" 3315 > client), does it do both in parallel, initiate stateful (Solicits) and > failover to stateless at some point (and does it continue to > do stateful in the background), or? These areas that are not well > documented in the DHCPv6 specifications (3315 + 3736) and we > need to clarify. We've discussed several proposals but I don't think > we've closed that discussion. Exactly, > Thus, I would suggest we: > - Have one bit that says "run DHCPv6". If the client is stateful, it > does "full" 3315". If the client is stateless (3736), it does stateless > only. > - Have the DHC WG publish a draft to properly define the behavior of > clients (and servers) when stateful service is not available and only > stateless is available. IE, when should a client switch to using > Information-Request or should all servers support Solicit and > should an Advertise be able to carry "other configuration" options > when addresses are not available. (Or perhaps there are other options > to be considered.) As Jinmei pointed out, we should consider *backward-incompatibility* proir to saying any alternatives. We should make sure that is not a trivial consideration. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 24 23:23:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamUX-0003xi-BJ; Tue, 24 May 2005 23:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamUU-0003xa-5F; Tue, 24 May 2005 23:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20340; Tue, 24 May 2005 23:23:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Damml-0004oq-4G; Tue, 24 May 2005 23:42:25 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 May 2005 23:23:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4P3N05A004470; Tue, 24 May 2005 23:23:15 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 23:23:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 23:23:09 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB213387C9@xmb-rtp-20a.amer.cisco.com> Thread-Topic: purpose of m/o bit Thread-Index: AcVg1/67duxFQIKcR3q8iX4krsvUxQAANLwQ From: "Bernie Volz \(volz\)" To: "Soohong Daniel Park@samsung.com" , "Bound, Jim" , "Thomas Narten" , , X-OriginalArrivalTime: 25 May 2005 03:23:12.0117 (UTC) FILETIME=[14AFEA50:01C560D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I don't have any issues if we wanted to keep 2 bits - just figured simpler is better. Note that if we drop one of those bits, we would not want to reuse if for another purpose for a long time -- that would allow backward compatibility for those environments that need it. But again, I really don't care if it is two bits. - Bernie=20 > -----Original Message----- > From: Soohong Daniel Park@samsung.com=20 > [mailto:soohong.park@samsung.com]=20 > Sent: Tuesday, May 24, 2005 11:15 PM > To: Bernie Volz (volz); 'Bound, Jim'; 'Thomas Narten';=20 > ipv6@ietf.org; dhcwg@ietf.org > Subject: RE: purpose of m/o bit >=20 > > But if the client supports both (really this means it is a=20 > "full" 3315 > > client), does it do both in parallel, initiate stateful=20 > (Solicits) and > > failover to stateless at some point (and does it continue to=20 > > do stateful in the background), or? These areas that are not well=20 > > documented in the DHCPv6 specifications (3315 + 3736) and we=20 > > need to clarify. We've discussed several proposals but I=20 > don't think=20 > > we've closed that discussion. >=20 > Exactly, >=20 > > Thus, I would suggest we: > > - Have one bit that says "run DHCPv6". If the client is stateful, it > > does "full" 3315". If the client is stateless (3736), it=20 > does stateless > > only. > > - Have the DHC WG publish a draft to properly define the behavior of > > clients (and servers) when stateful service is not=20 > available and only > > stateless is available. IE, when should a client switch to using > > Information-Request or should all servers support Solicit and=20 > > should an Advertise be able to carry "other configuration" options=20 > > when addresses are not available. (Or perhaps there are=20 > other options=20 > > to be considered.) >=20 > As Jinmei pointed out, we should consider *backward-incompatibility* > proir to saying any alternatives. We should make sure that is=20 > not a trivial=20 > consideration.=20 >=20 >=20 >=20 > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 00:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DanCd-0003ml-L7; Wed, 25 May 2005 00:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DanCa-0003md-29; Wed, 25 May 2005 00:09:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26174; Wed, 25 May 2005 00:09:00 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DanUs-0006Ym-3Z; Wed, 25 May 2005 00:27:59 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH1006RC26ATF@mailout1.samsung.com>; Wed, 25 May 2005 13:08:34 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH100IU126AXW@mmp1.samsung.com>; Wed, 25 May 2005 13:08:34 +0900 (KST) Date: Wed, 25 May 2005 13:08:29 +0900 From: "Soohong Daniel Park@samsung.com" In-reply-to: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> To: "'Thomas Narten'" , ipv6@ietf.org Message-id: <010801c560df$68a4c710$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? YES > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) YES > If we can't agree that the above is necessary (i.e., is a "problem > statement" of sorts), I really have to wonder what purpose the R/A > bits can serve or whether we will ever have a shared understanding of > what they are supposed to do. Having them be a hint (that clients in > practice ignore half the time) would seem to solve no useful purpose > (IMO) and would provide the sys admin with useless tools (since > clients wouldn't respond to the usage of the tool in predicatable > ways). The result would simply be more confusion. (Oh, that is already > the state we are in!!! :-)) I don't think we (folks) do not agree on above necessary. We may need more simplified method to achieve above than now. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 00:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaneS-0000Rk-0f; Wed, 25 May 2005 00:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaneM-0000R5-Ej; Wed, 25 May 2005 00:37:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28571; Wed, 25 May 2005 00:37:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Danwe-0007pL-QX; Wed, 25 May 2005 00:56:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 00:37:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4P4bUl6011351; Wed, 25 May 2005 00:37:32 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 00:37:29 -0400 Received: from 10.86.240.56 ([10.86.240.56]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 May 2005 04:37:29 +0000 Received: from localhost.localdomain by email.cisco.com; 25 May 2005 00:37:39 -0400 Subject: Re: [dhcwg] Re: Original intent of M/O bits From: Ralph Droms To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 22:39:41 -0400 Message-Id: <1116988781.5389.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 25 May 2005 04:37:29.0964 (UTC) FILETIME=[75C562C0:01C560E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , dhcwg@ietf.org, IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Regarding breaking backward compatibility - this compatibility affects only clients, right? Can we answer the question: exactly how would existing clients (and I'll bet we can enumerate all the available clients) be affected by a change in definition? How would the observed behavior of the clients be out-of-spec relative to the new definition? I ask because I'd be willing to bet the observed behavior of existing clients will still be in compliance with the new definition: when the M bit is set, the client will attempt HCB and when the O bit is set the client will attempt ICB. When both are set, I'll bet the client tries HCB, which is still compliant with a new definition of M bit as a hint. - Ralph On Wed, 2005-05-25 at 10:47 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > >>>>> On Tue, 24 May 2005 10:46:06 -0400,=20 > >>>>> Thomas Narten said: >=20 > >> If we respect both the original sense of RFC2462 and our consensus > >> about the semantics separation of the M/O flags, I believe the right > >> solution is the following: >=20 > > I think we should be careful NOT to get hung up on what the original > > intent of the M/O bits were, but focus on what the right behavior > > should be, given what we know now/today, and given the DHC protocols > > we actually have. >=20 > In general, I agree (if I sound self-conflicting, note the "If" in the > cited part above). In practice, however, it should also be noted that > one major push back argument in the similar discussion for rfc2462bis > a year ago was that we should not introduce incompatible changes to > existing implementations that assume the "original intent". >=20 > It seems to me that this is a typical case of tradeoff between "it's > never too late to do the right thing" vs "don't break compatibility". > In the previous discussion, the latter was preferred, and so we are > here. If we can now prefer the former argument, I'm personally > willing to take it. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > 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-bounces@ietf.org Wed May 25 01:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daomi-0005Db-MD; Wed, 25 May 2005 01:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daome-0005CI-L2; Wed, 25 May 2005 01:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02665; Wed, 25 May 2005 01:50:23 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dap4x-0001hb-QB; Wed, 25 May 2005 02:09:21 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2456815218; Wed, 25 May 2005 14:52:50 +0900 (JST) Date: Wed, 25 May 2005 14:51:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] Re: Original intent of M/O bits In-Reply-To: <1116988781.5389.5.camel@localhost.localdomain> References: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> <1116988781.5389.5.camel@localhost.localdomain> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Thomas Narten , dhcwg@ietf.org, IPv6 WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 May 2005 22:39:41 -0400, >>>>> Ralph Droms said: > Regarding breaking backward compatibility - this compatibility affects > only clients, right? Can we answer the question: exactly how would > existing clients (and I'll bet we can enumerate all the available > clients) be affected by a change in definition? How would the observed > behavior of the clients be out-of-spec relative to the new definition? It depends on the details of the "new definition". For example, a "radical" change like removing the flags altogether would break the compatibility. I cannot be more specific at the moment, since the original message from Thomas did not show specific ideas... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 07:34:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dau9i-0002CU-1p; Wed, 25 May 2005 07:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCNG-0001Aa-8R; Mon, 23 May 2005 08:49:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21391; Mon, 23 May 2005 08:49:37 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCfE-0002F8-M2; Mon, 23 May 2005 09:08:13 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4NCmc2Z029105 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 May 2005 14:48:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1116615963.11164.60.camel@localhost.localdomain> References: <1116615963.11164.60.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <668F63E6-A4E0-4993-8E9C-DDAF7553C572@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 23 May 2005 14:48:24 +0200 To: Ralph Droms X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 May 2005 07:34:33 -0400 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: meta thoughts on m/o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 20-mei-2005, at 21:06, Ralph Droms wrote: >> In some scenarios there is a danger in the following approach: >> - hosts boots >> - looks for DHCP server, doesn't find one >> - Keeps looking every couple of minutes Yes, this would clearly be harmful in cases where hosts both use DHCPv6 and stateless autoconfiguration, but no DHCPv6 server is available. This especially adds up when there are many hosts on the subnet. > A client is free to use some other timeout (2 hours instead of 2 > minutes?) if it chooses. How is this useful? Either I want to know that a DHCPv6 server has become available, so waiting 2 hours is way too long, or I don't care, so why bother checking in the first place? The situation where a server broadcasts its existence makes MUCH more sense. But the real question is: how do we know we want to use DHCPv6 in the first place? Obviously in many cases the answer is simple: yes, I want it all the time, or no, I never want it. But suppose some networks adopt DHCPv6 in lieu of stateless autoconfiguration for reasons that make sense to them (and work elsewhere, such as shim6, _may_ make this a somewhat more likely situation). It would then make sense for a laptop or similar client to have both stateless autoconfiguration and DHCPv6 on board for autoconfiguration. However, such a client wouldn't have any idea about the availability of either mechanism or their preference. Since presumably, DHCPv6 won't be available in many cases, an agnostic host wouldn't want to wait for DHCPv6 to fail when stateless autoconfig is available. On the other hand, some admins may strongly prefer hosts to use DHCPv6, but provide stateless autoconfig as a fallback for hosts that don't support DHCPv6. In that case, it would be better to ignore stateless autoconfig altogether when DHCPv6 works. The real problems start when DHCPv6 is preferred, but there is some kind of failure. Obviously the host should use stateless autoconfig in the mean time, but it would be useful if it were to switch to DHCPv6 as soon as the server becomes available. So what we really need is a mechanism that says: - DHCPv6 isn't available so don't bother with it - DHCPv6 is available, but use stateless autoconfig unless you can't/ won't - DHCPv6 is available and equal to stateless autoconfig, use either but no need to use both - DHCPv6 is available and equal to stateless autoconfig, use both - DHCPv6 is available and preferred, use it exclusively if you can Something similar is probably needed for the O flag. In addition, it would be useful to have some kind of flag that indicates that the DHCPv6 server status has changed so hosts should refresh their leases and other information. Obviously all of this can't be accommodated with two bits in RAs. So we can: - forget the whole thing and let the implementers/admins figure it out - hammer on it until it fits in the m and o bits - come up with an RA/ND option that has room for all of this (It would be cool to find a way to integrate DHCPv6 and RAs to some degree, though. For instance, by allowing DHCP options in RA options.) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 07:34:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dau9i-0002Ct-D7; Wed, 25 May 2005 07:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dasc9-0003zM-Nv; Wed, 25 May 2005 05:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23384; Wed, 25 May 2005 05:55:47 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DasuU-0008DR-4G; Wed, 25 May 2005 06:14:48 -0400 Received: from [194.229.202.133] ([194.229.202.133]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4P9tR2Z068998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 May 2005 11:55:46 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> References: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 25 May 2005 11:43:07 +0200 To: Thomas Narten X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 May 2005 07:34:33 -0400 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org [Crossposted to dhcwg even though I'm not on that list, as people there may be able to add some useful insights.] On 24-mei-2005, at 16:45, Thomas Narten wrote: > I wonder if there is key question here that the community has simply > not agreed on (yet), and that that question is at the heart of all > this "confusion". > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? By a strange coincidence, I spent most of the day yesterday taking several DHCPv6 implementations for a test drive, for reasons unrelated to this discussion. These implementations are: KAME DHCP6, the unnamed Linux fork of the KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco IOS implemenation. Conclusion: the Cisco implementation is incomplete (no address assignment) and the other two are too immature to be of much use. I'm impressed with the prefix delegation functionality, but as before, the prospect of running such a complex protocol just to optain a domain search list and some DNS resolvers makes me very uncomfortable. All of this, coupled with the fact that, AFAIK, no OS implements DHCPv6, means that there is essentially zero experience with DHCPv6 in the operational community. This means that at this time, there is little point in asking the operational community what should happen with the M and O bits. In other words: this is not the time declare the bits useless and remove them. > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) Depends. There are three possible ways this can play out: - the DNS resolver issue is solved in a way that doesn't requite DHCP, so most people don't don't run DHCPv6 at all, others run it all the time -> no bits necessary - the DNS resolver issue isn't solved in another way, so everyone runs some form of DHCPv6 all the time -> no bits necessary - DHCP provides benefits but some people are reluctant to use it -> helpful to know whether to bother running DHCPv6 > For example, should the sys admin be able to say "do not run DHC, > doing so wastes local resources and won't get you any config info"? > (And should that be honored by clients?) I think it's good to recognize that in the past, there have often been security issues with non-text based UDP protocols, so knowing there is no need to run DHCP and then not running it would be good security. > Fundamentally, it is only the access network that has knowledge of > whether running DHC is useful. Thus, by default, clients (arguably) > can't know whether running DHC is useful, so by default they shold > invoke DHC (unless the sys admin signals "don't invoke DHC"). > Or (switching the argument), by default, client should not invoke DHC, > unless the local sys admin indicates doing so is appropriate. There isn't really a difference here, except for what happens when there are no RAs. I would be interested in hearing viewpoints on the usefulness of running DHCPv6 even though the hints indicate that there is no need to. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 07:34:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dau9i-0002DI-Nf; Wed, 25 May 2005 07:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DascP-00042L-T2; Wed, 25 May 2005 05:56:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23397; Wed, 25 May 2005 05:56:03 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dasum-0008Dy-Hv; Wed, 25 May 2005 06:15:04 -0400 Received: from [194.229.202.133] ([194.229.202.133]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4P9tR2a068998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 May 2005 11:55:55 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <936A4045C332714F975800409DE092404A0BF8@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092404A0BF8@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70760F06-F8FF-4694-94B8-7E2478FE36AB@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 25 May 2005 11:45:44 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 May 2005 07:34:33 -0400 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 24-mei-2005, at 18:10, Bound, Jim wrote: > Bernie, I think your honing down to valid points. I view m bit set > implying o bit use too. but that is not stated. RFC 2462: In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well. It is not a valid configuration for a host to use stateful address autoconfiguration to request addresses only, without also accepting other configuration information. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 13:22:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daza0-00027s-Pl; Wed, 25 May 2005 13:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DazZy-00027k-Jw; Wed, 25 May 2005 13:22:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02294; Wed, 25 May 2005 13:21:59 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DazsK-0003aQ-A2; Wed, 25 May 2005 13:41:05 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1db7:2189:3231:e775]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3609415218; Thu, 26 May 2005 02:24:28 +0900 (JST) Date: Thu, 26 May 2005 02:22:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum Subject: Re: [dhcwg] Re: purpose of m/o bit In-Reply-To: <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> References: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Thomas Narten , dhcwg@ietf.org, IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Wed, 25 May 2005 11:43:07 +0200, >>>>> Iljitsch van Beijnum said: > These implementations are: KAME DHCP6, the unnamed Linux fork of the > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco > IOS implemenation. > Conclusion: the Cisco implementation is incomplete (no address > assignment) and the other two are too immature to be of much use. > I'm impressed with the prefix delegation functionality, but as > before, the prospect of running such a complex protocol just to > optain a domain search list and some DNS resolvers makes me very > uncomfortable. A quick check (which may not be relevant to this thread): what exactly do you mean by such a complex protocol? Whole RFC3315 (mainly for address allocation), the RFC3736 subset, or both? If your goal is to obtain a domain search list and recursive name (DNS) servers, you only need the RFC3736 subset, and at least I'd not use the strong phrase "such a complex protocol" for RFC3736. Implementation maturity is a separate issue. I admit KAME's DHCPv6 implementation is not so matured yet, particularly regarding its address allocation functionality. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 13:39:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dazqk-0005Zr-PX; Wed, 25 May 2005 13:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dazqh-0005Zj-1f; Wed, 25 May 2005 13:39:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03585; Wed, 25 May 2005 13:39:16 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db096-0003xl-Pc; Wed, 25 May 2005 13:58:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: purpose of m/o bit Date: Wed, 25 May 2005 13:38:51 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7309CB45@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVhHmGDmhPx71eeTiSg0e2QoYJwKAAMSD8A From: "Woundy, Richard" To: "Iljitsch van Beijnum" , "Thomas Narten" X-OriginalArrivalTime: 25 May 2005 17:38:52.0578 (UTC) FILETIME=[9DFC9020:01C56150] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >All of this, coupled with the fact that, AFAIK, no OS implements DHCPv6, means that there is essentially zero experience with DHCPv6 in the operational community. This means that at this time, there is little point in asking the operational community what should happen with the M and O bits. Or perhaps this could be the ideal time to ask the operational community what should happen with the M and O bits -- before software developers go too far down a particular direction without operator guidance? Some of us operators do more than just configure and test vendor products. -- Rich -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Wednesday, May 25, 2005 5:43 AM To: Thomas Narten Cc: dhcwg@ietf.org; IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit [Crossposted to dhcwg even though I'm not on that list, as people =20 there may be able to add some useful insights.] On 24-mei-2005, at 16:45, Thomas Narten wrote: > I wonder if there is key question here that the community has simply=20 > not agreed on (yet), and that that question is at the heart of all=20 > this "confusion". > Does the community feel that operators need RA bits that=20 > control/indicate whether a client is to invoke DHC? That is, is there=20 > a need for the sys admin to signal to client whether DHC is to be=20 > invoked? By a strange coincidence, I spent most of the day yesterday taking =20 several DHCPv6 implementations for a test drive, for reasons =20 unrelated to this discussion. These implementations are: KAME DHCP6, the unnamed Linux fork of the =20 KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco =20 IOS implemenation. Conclusion: the Cisco implementation is incomplete (no address =20 assignment) and the other two are too immature to be of much use. I'm impressed with the prefix delegation functionality, but as =20 before, the prospect of running such a complex protocol just to =20 optain a domain search list and some DNS resolvers makes me very =20 uncomfortable. All of this, coupled with the fact that, AFAIK, no OS implements =20 DHCPv6, means that there is essentially zero experience with DHCPv6 =20 in the operational community. This means that at this time, there is =20 little point in asking the operational community what should happen =20 with the M and O bits. In other words: this is not the time declare the bits useless and =20 remove them. > Second, is it important that such a signal be honored by clients?=20 > (That is, if clients end up mostly ignoring the flags, does their=20 > presence become useless?) Depends. There are three possible ways this can play out: - the DNS resolver issue is solved in a way that doesn't requite =20 DHCP, so most people don't don't run DHCPv6 at all, others run it all =20 the time -> no bits necessary - the DNS resolver issue isn't solved in another way, so everyone =20 runs some form of DHCPv6 all the time -> no bits necessary - DHCP provides benefits but some people are reluctant to use it -> =20 helpful to know whether to bother running DHCPv6 > For example, should the sys admin be able to say "do not run DHC,=20 > doing so wastes local resources and won't get you any config info"?=20 > (And should that be honored by clients?) I think it's good to recognize that in the past, there have often =20 been security issues with non-text based UDP protocols, so knowing =20 there is no need to run DHCP and then not running it would be good =20 security. > Fundamentally, it is only the access network that has knowledge of=20 > whether running DHC is useful. Thus, by default, clients (arguably)=20 > can't know whether running DHC is useful, so by default they shold=20 > invoke DHC (unless the sys admin signals "don't invoke DHC"). > Or (switching the argument), by default, client should not invoke DHC, > unless the local sys admin indicates doing so is appropriate. There isn't really a difference here, except for what happens when =20 there are no RAs. I would be interested in hearing viewpoints on the usefulness of =20 running DHCPv6 even though the hints indicate that there is no need to. _______________________________________________ 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-bounces@ietf.org Wed May 25 13:55:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db065-0008BM-3l; Wed, 25 May 2005 13:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db060-0008Aj-51; Wed, 25 May 2005 13:55:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04509; Wed, 25 May 2005 13:55:07 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db0OO-0004IH-W3; Wed, 25 May 2005 14:14:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 13:54:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4PHsI5O024436; Wed, 25 May 2005 13:54:54 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 13:54:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: purpose of m/o bit Date: Wed, 25 May 2005 13:54:51 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB213388DD@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVhHmGDmhPx71eeTiSg0e2QoYJwKAAMSD8AAADP6CA= From: "Bernie Volz \(volz\)" To: "Woundy, Richard" , "Iljitsch van Beijnum" , "Thomas Narten" X-OriginalArrivalTime: 25 May 2005 17:54:52.0679 (UTC) FILETIME=[DA405970:01C56152] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org So Rich, I'll ask. What would you like to see happen? - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Woundy, Richard > Sent: Wednesday, May 25, 2005 1:39 PM > To: Iljitsch van Beijnum; Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: RE: [dhcwg] Re: purpose of m/o bit >=20 > >All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 in > the operational community. This means that at this time,=20 > there is little > point in asking the operational community what should happen=20 > with the M > and O bits. >=20 > Or perhaps this could be the ideal time to ask the=20 > operational community > what should happen with the M and O bits -- before software developers > go too far down a particular direction without operator guidance? >=20 > Some of us operators do more than just configure and test vendor > products. >=20 > -- Rich >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Iljitsch van Beijnum > Sent: Wednesday, May 25, 2005 5:43 AM > To: Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 >=20 > [Crossposted to dhcwg even though I'm not on that list, as people =20 > there may be able to add some useful insights.] >=20 > On 24-mei-2005, at 16:45, Thomas Narten wrote: >=20 > > I wonder if there is key question here that the community=20 > has simply=20 > > not agreed on (yet), and that that question is at the heart of all=20 > > this "confusion". >=20 > > Does the community feel that operators need RA bits that=20 > > control/indicate whether a client is to invoke DHC? That=20 > is, is there=20 > > a need for the sys admin to signal to client whether DHC is to be=20 > > invoked? >=20 > By a strange coincidence, I spent most of the day yesterday taking =20 > several DHCPv6 implementations for a test drive, for reasons =20 > unrelated to this discussion. >=20 > These implementations are: KAME DHCP6, the unnamed Linux fork of the =20 > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco =20 > IOS implemenation. >=20 > Conclusion: the Cisco implementation is incomplete (no address =20 > assignment) and the other two are too immature to be of much use. >=20 > I'm impressed with the prefix delegation functionality, but as =20 > before, the prospect of running such a complex protocol just to =20 > optain a domain search list and some DNS resolvers makes me very =20 > uncomfortable. >=20 > All of this, coupled with the fact that, AFAIK, no OS implements =20 > DHCPv6, means that there is essentially zero experience with DHCPv6 =20 > in the operational community. This means that at this time, there is =20 > little point in asking the operational community what should happen =20 > with the M and O bits. >=20 > In other words: this is not the time declare the bits useless and =20 > remove them. >=20 > > Second, is it important that such a signal be honored by clients?=20 > > (That is, if clients end up mostly ignoring the flags, does their=20 > > presence become useless?) >=20 > Depends. There are three possible ways this can play out: >=20 > - the DNS resolver issue is solved in a way that doesn't requite =20 > DHCP, so most people don't don't run DHCPv6 at all, others=20 > run it all =20 > the time -> no bits necessary > - the DNS resolver issue isn't solved in another way, so everyone =20 > runs some form of DHCPv6 all the time -> no bits necessary > - DHCP provides benefits but some people are reluctant to use it -> =20 > helpful to know whether to bother running DHCPv6 >=20 > > For example, should the sys admin be able to say "do not run DHC,=20 > > doing so wastes local resources and won't get you any config info"?=20 > > (And should that be honored by clients?) >=20 > I think it's good to recognize that in the past, there have often =20 > been security issues with non-text based UDP protocols, so knowing =20 > there is no need to run DHCP and then not running it would be good =20 > security. >=20 > > Fundamentally, it is only the access network that has knowledge of=20 > > whether running DHC is useful. Thus, by default, clients (arguably)=20 > > can't know whether running DHC is useful, so by default they shold=20 > > invoke DHC (unless the sys admin signals "don't invoke DHC"). >=20 > > Or (switching the argument), by default, client should not=20 > invoke DHC, >=20 > > unless the local sys admin indicates doing so is appropriate. >=20 > There isn't really a difference here, except for what happens when =20 > there are no RAs. >=20 > I would be interested in hearing viewpoints on the usefulness of =20 > running DHCPv6 even though the hints indicate that there is=20 > no need to. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 16:46:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db2lm-0000wX-Us; Wed, 25 May 2005 16:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db2lg-0000wF-CK; Wed, 25 May 2005 16:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27950; Wed, 25 May 2005 16:46:18 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db346-00030a-Us; Wed, 25 May 2005 17:05:24 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.11138753; Wed, 25 May 2005 16:45:47 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 16:45:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: purpose of m/o bit Date: Wed, 25 May 2005 16:45:41 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7309CB4D@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVhHmGDmhPx71eeTiSg0e2QoYJwKAAMSD8AAADP6CAAAR8RIA== From: "Woundy, Richard" To: "Bernie Volz \(volz\)" , "Iljitsch van Beijnum" , "Thomas Narten" X-OriginalArrivalTime: 25 May 2005 20:45:42.0295 (UTC) FILETIME=[B77FA270:01C5616A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Folks, I can't speak on behalf of all cable operators, but I can provide my own current perspective on IPv6 and the M/O flags. There are three primary types of DHCPv4 clients in cable networks today: cable modems, functional entities co-resident with the cable modems (such as PacketCable MTA VoIP endpoints, CableHome gateways, etc.), and customer computers and other customer-controlled equipment. For our business, we want the ability to control which prefixes were assigned to which customer devices. For example, we may want to assign different prefixes to devices corresponding to non-customers and to "not-yet-customers" (those that will self-provision their service). Our current plans are that cable modems and co-resident functional entities would use DHCPv6 for stateful address configuration as part of their own boot process. DHCPv6 would also provide information for configuration downloads, time servers, and domain name servers (as needed). I don't think we would want to use address autoconfiguration for those devices/entities. Customer computers and other customer equipment tend to be a little trickier, since such devices may be used in different service provider contexts (e.g. wireless, where bandwidth is much more precious than in cable), and since OS developers don't always worry about service provider network requirements (especially if they are focused on personal computing or enterprise network/IT requirements first). One possible approach is that cable modems (or some subset of cable modems) would use DHCPv6 prefix delegation (PD) to get a customer-specific prefix, which could be learned by customer computers through address autoconfiguration (e.g. the cable modem would become an IPv6 router). The customer computers could use DHCPv6 (ala RFC 3736) to obtain additional parameters (e.g. domain name servers), but DHCPv6 use would be optional for network access. This plan presumes that PD scales for our customer base, which today is largely residential broadband customers. The other approach is that each customer computer would use DHCPv6 for stateful address configuration. This matches our current IPv4 deployment model where every customer computer is a DHCPv4 client of our DHCP servers. But this approach would mandate DHCPv6 use for network access, which may be fairly painful when there are few/no DHCPv6 client implementations in OS's today. :^( What does that mean for the M/O flags discussion? I suspect we might try to deploy both approaches for customer computer address allocation, which would imply that we would want to use something like the M/O flags to signal to customer computers when DHCPv6 is necessary for network access, and when it is not. While we expect cable modems to use DHCPv6 exclusively, I have heard of other cable operators that want to experiment with address autoconfig for cable modems -- although to be honest I am not really sure how that would work. I would think it is our responsibility (as service providers) to set the M/O flag settings correctly and appropriately on our edge routers (CMTSs). Hope this perspective helps. -- Rich -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, May 25, 2005 1:55 PM To: Woundy, Richard; Iljitsch van Beijnum; Thomas Narten Cc: dhcwg@ietf.org; IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit So Rich, I'll ask. What would you like to see happen? - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Woundy, Richard > Sent: Wednesday, May 25, 2005 1:39 PM > To: Iljitsch van Beijnum; Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: RE: [dhcwg] Re: purpose of m/o bit >=20 > >All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 in > the operational community. This means that at this time, there is=20 > little point in asking the operational community what should happen > with the M > and O bits. >=20 > Or perhaps this could be the ideal time to ask the > operational community > what should happen with the M and O bits -- before software developers > go too far down a particular direction without operator guidance? >=20 > Some of us operators do more than just configure and test vendor=20 > products. >=20 > -- Rich >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Iljitsch van Beijnum > Sent: Wednesday, May 25, 2005 5:43 AM > To: Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 >=20 > [Crossposted to dhcwg even though I'm not on that list, as people > there may be able to add some useful insights.] >=20 > On 24-mei-2005, at 16:45, Thomas Narten wrote: >=20 > > I wonder if there is key question here that the community > has simply > > not agreed on (yet), and that that question is at the heart of all > > this "confusion". >=20 > > Does the community feel that operators need RA bits that > > control/indicate whether a client is to invoke DHC? That=20 > is, is there > > a need for the sys admin to signal to client whether DHC is to be > > invoked? >=20 > By a strange coincidence, I spent most of the day yesterday taking > several DHCPv6 implementations for a test drive, for reasons =20 > unrelated to this discussion. >=20 > These implementations are: KAME DHCP6, the unnamed Linux fork of the > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco =20 > IOS implemenation. >=20 > Conclusion: the Cisco implementation is incomplete (no address > assignment) and the other two are too immature to be of much use. >=20 > I'm impressed with the prefix delegation functionality, but as > before, the prospect of running such a complex protocol just to =20 > optain a domain search list and some DNS resolvers makes me very =20 > uncomfortable. >=20 > All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 =20 > in the operational community. This means that at this time, there is =20 > little point in asking the operational community what should happen =20 > with the M and O bits. >=20 > In other words: this is not the time declare the bits useless and > remove them. >=20 > > Second, is it important that such a signal be honored by clients? > > (That is, if clients end up mostly ignoring the flags, does their=20 > > presence become useless?) >=20 > Depends. There are three possible ways this can play out: >=20 > - the DNS resolver issue is solved in a way that doesn't requite > DHCP, so most people don't don't run DHCPv6 at all, others=20 > run it all =20 > the time -> no bits necessary > - the DNS resolver issue isn't solved in another way, so everyone =20 > runs some form of DHCPv6 all the time -> no bits necessary > - DHCP provides benefits but some people are reluctant to use it -> =20 > helpful to know whether to bother running DHCPv6 >=20 > > For example, should the sys admin be able to say "do not run DHC, > > doing so wastes local resources and won't get you any config info"?=20 > > (And should that be honored by clients?) >=20 > I think it's good to recognize that in the past, there have often > been security issues with non-text based UDP protocols, so knowing =20 > there is no need to run DHCP and then not running it would be good =20 > security. >=20 > > Fundamentally, it is only the access network that has knowledge of > > whether running DHC is useful. Thus, by default, clients (arguably)=20 > > can't know whether running DHC is useful, so by default they shold=20 > > invoke DHC (unless the sys admin signals "don't invoke DHC"). >=20 > > Or (switching the argument), by default, client should not > invoke DHC, >=20 > > unless the local sys admin indicates doing so is appropriate. >=20 > There isn't really a difference here, except for what happens when > there are no RAs. >=20 > I would be interested in hearing viewpoints on the usefulness of > running DHCPv6 even though the hints indicate that there is=20 > no need to. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 18:46:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4eC-0005Kn-UC; Wed, 25 May 2005 18:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4eB-0005Ki-DL for dhcwg@megatron.ietf.org; Wed, 25 May 2005 18:46:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05853 for ; Wed, 25 May 2005 18:46:40 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db4wd-0005Nc-Qp for dhcwg@ietf.org; Wed, 25 May 2005 19:05:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 18:46:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4PMkU4u025353 for ; Wed, 25 May 2005 18:46:30 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 18:46:29 -0400 Received: from 10.86.242.165 ([10.86.242.165]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 May 2005 22:46:29 +0000 Received: from localhost.localdomain by email.cisco.com; 25 May 2005 18:46:57 -0400 From: Ralph Droms To: dhcwg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 25 May 2005 18:46:56 -0400 Message-Id: <1117061216.5398.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 25 May 2005 22:46:29.0998 (UTC) FILETIME=[977758E0:01C5617B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhc WG last call on X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "Resolution of DNS Name Conflicts among DHCP Clients" . The last call will conclude at 1700 EST (USA) on 2005-04-25. Please respond to this WG last call. Note that this is the *second* last call for this document. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. If you commented about this document between the first last call and this new last call, please repost your comment so we can be sure to assess all support for the document. Summary: There are options in DHCP that can be used for transmitting information about updating DNS. However, these do not explicitly control updating the name to address and address to name mappings maintained in the DNS, as performed by hosts acting as DHCP clients and servers. draft-ietf-dhc-ddns-resolution-08.txt describes techniques for the resolution of DNS name conflicts among DHCP clients and servers. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns- resolution-08.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 18:46:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4eI-0005LS-Le; Wed, 25 May 2005 18:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4eH-0005LN-S2 for dhcwg@megatron.ietf.org; Wed, 25 May 2005 18:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05856 for ; Wed, 25 May 2005 18:46:47 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db4wk-0005Nc-BN for dhcwg@ietf.org; Wed, 25 May 2005 19:05:55 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 18:46:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4PMkjl6023429 for ; Wed, 25 May 2005 18:46:45 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 18:46:45 -0400 Received: from 10.86.242.165 ([10.86.242.165]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 May 2005 22:46:45 +0000 Received: from localhost.localdomain by email.cisco.com; 25 May 2005 18:47:12 -0400 From: Ralph Droms To: dhcwg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 25 May 2005 18:47:11 -0400 Message-Id: <1117061232.5398.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 25 May 2005 22:46:45.0137 (UTC) FILETIME=[A07D6010:01C5617B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhc WG last call on CORRECTION X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "Resolution of DNS Name Conflicts among DHCP Clients" . The last call will conclude at 1700 EST (USA) on 2005-06-08 (note corrected date for conclusion of this last call). Please respond to this WG last call. Note that this is the *second* last call for this document. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. If you commented about this document between the first last call and this new last call, please repost your comment so we can be sure to assess all support for the document. Summary: There are options in DHCP that can be used for transmitting information about updating DNS. However, these do not explicitly control updating the name to address and address to name mappings maintained in the DNS, as performed by hosts acting as DHCP clients and servers. draft-ietf-dhc-ddns-resolution-08.txt describes techniques for the resolution of DNS name conflicts among DHCP clients and servers. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns- resolution-08.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed May 25 18:47:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4el-0005OR-4R; Wed, 25 May 2005 18:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db4ej-0005OG-Ai for dhcwg@megatron.ietf.org; Wed, 25 May 2005 18:47:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05877 for ; Wed, 25 May 2005 18:47:14 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db4xB-0005Nz-TI for dhcwg@ietf.org; Wed, 25 May 2005 19:06:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 18:47:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4PMl34w025494 for ; Wed, 25 May 2005 18:47:05 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 18:47:04 -0400 Received: from 10.86.242.165 ([10.86.242.165]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 May 2005 22:47:04 +0000 Received: from localhost.localdomain by email.cisco.com; 25 May 2005 18:47:31 -0400 Subject: [dhcwg] dhc WG last call on "DHCP Preboot eXecution Environment (PXE) Options" From: Ralph Droms To: dhcwg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 25 May 2005 18:47:31 -0400 Message-Id: <1117061251.5398.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 25 May 2005 22:47:04.0607 (UTC) FILETIME=[AC1842F0:01C5617B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a WG last call on "DHCP Preboot eXecution Environment (PXE) Options" . The last call will conclude at 1700 ET on 2005-06-08. Please respond to this WG last call. This last call is the *second* last call on this document. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. I will follow up on the one substantive comment received during the previous last call in a separate message. This document includes revisions based on the WG last call on the previous revision, draft-ietf-dhc-pxe-options-00.txt. Summary: "DHCP Preboot eXecution Environment (PXE) Options" documents the definition of DHCP options used by PXE and EFI clients. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 12:01:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKnb-0004kV-NC; Thu, 26 May 2005 12:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKnY-0004k3-TH for dhcwg@megatron.ietf.org; Thu, 26 May 2005 12:01:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08607 for ; Thu, 26 May 2005 12:01:26 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbL69-0004OR-Rj for dhcwg@ietf.org; Thu, 26 May 2005 12:20:43 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 May 2005 12:01:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4QG0d5Q011203 for ; Thu, 26 May 2005 12:01:14 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 12:01:12 -0400 Received: from 10.86.240.1 ([10.86.240.1]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 16:01:12 +0000 Received: from localhost.localdomain by email.cisco.com; 26 May 2005 12:01:41 -0400 Subject: Re: [dhcwg] dhc WG last call on From: Ralph Droms To: dhcwg@ietf.org In-Reply-To: <1117061216.5398.31.camel@localhost.localdomain> References: <1117061216.5398.31.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 26 May 2005 12:01:40 -0400 Message-Id: <1117123301.6323.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 26 May 2005 16:01:12.0264 (UTC) FILETIME=[23615C80:01C5620C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org In general, I think the mechanism specified in this document is fully baked and useful. I do have some substantive comments and many editorial comments: Substantive comments: The Terminology section should have a list of acronyms and terms used in the doc; e.g., FQDN, Name Conflict, MCNS The Abstract is not clear and does not accurately reflect the intent and the contents of the doc. I suggest: Abstract DHCP provides a mechanism for host configuration that includes dynamic assignment of IP addresses. To maintain accurate IP address and IP address to name mappings in the DNS, these dynamically assigned addresses require updates to the DNS. Conflicts may arise between updates to the DNS from different sources. This document describes techniques for the resolution of DNS name conflicts arising from updates to the DNS to reflect dynamic IP address assignment. I read the last sentence of the first paragraph of 3.1 to imply that Secure DNS can mitigate the problem of name conflicts. Can Secure DNS mitigate or preclude name conflicts; I'm not sure it has any effect on name conflicts: Sites that deploy Secure DNS [10] may configure credentials for each host and its assigned name in a way that is more -error-resistant, but this level of pre-configuration is still rare in DHCP environments. I knew to look for it, but found that the explanation in draft-ietf-dnsext-dhcid-rr of how to use the new style of IPv4 client identifier defined in draft-ietf-dhc-3315id-for-v4 is obscure. I think it would be good, perhaps in a DISCUSSION, to point out that the use of 3315id-for-v4 identifiers leads to exactly the same data in the DHCID RR, because the DUID portion is encoded as an IPv6-style identifier. In the update mechanisms in section 6.3.2, is it possible for both the A and AAA RRs to be updated simultaneously? The text seems to refer to "A or AAAA" throughout section 6. What does "perform some name disambiguation operation on behalf of the current client" in the first paragraph of section 6.3.4 mean? Is there any possibility of a name conflict related to PTR records (section 6.4)? ----- Editorial comments: The term "lease" is often used where the terms "IP address" or "assigned IP address" would be more precise. "DNS name", "domain name" and "FQDN" are used interchangeably throughout the doc. For consistency, choose one term - I would recommend FQDN - and use it throughout. A and AAAA RRs are not mutually exclusive. The text should be edited to reflect that a client may have both A and AAAA RRs simultaneously. For example, in the first paragraph of section 2, change the third sentence: Through the use of the client FQDN option, DHCP clients and servers can negotiate the client's FQDN and the allocation of responsibility for updating the DHCP client's A [-or-] {+and+} AAAA [-RR.-] {+RRs.+} Both clients and servers can experience name conflicts. Change the last sentence of the first paragraph of section 2: This document identifies situations in which conflicts in the use of FQDNs may arise among DHCP [-clients,-] {+clients and servers,+} and describes a strategy for the use of the DHCID DNS resource record [2] in resolving those conflicts. The term "Name Conflict" is defined in the first paragraph of section 3 but not used anywhere else in the document (except in the title). Drop the definition? Change the first two sentences of section 3.1: [-At many (though not all) sites, administrators-] {+Administrators may+} wish to maintain a one-to-one relationship between active DHCP clients and domain names, and to maintain consistency between a host's [-A-] {+A, AAAA+} and PTR RRs. Hosts that are not represented in the DNS, or hosts [-which-] {+that+} inadvertently share an FQDN with another host may encounter inconsistent behavior or may not be able to obtain access to network resources. Change the last sentence of the first paragraph of section 3.1: Sites that deploy Secure DNS [10] may configure credentials for each host and its assigned name in a way that is more [-error-resistant, but this level of pre-configuration is still rare in DHCP environments.-] {+error-resistant.+} Change the last paragraph on page 4 (includes examples of replacing "lease" with the more precise "IP address" or "assigned IP address"): If the policy is that the first DHCP client with a given name should be the only client associated with that name, Client B needs to be able to determine [-that-] {+whether or not+} it is not the client associated with "foo.org.nil". It could be that Client A booted first, and that Client B should choose another name. Or it could be that B has booted on a new subnet, and received a new [-lease.-] {+IP address, in which case B should update the DNS with its new IP address.+} It must either retain persistent state about the last [-lease-] {+IP address+} it [-held-] {+was assigned+} (in addition to its current [-lease)-] {+IP address)+} or it must have some other way to detect that it was the last updater of "foo.org.nil" in order to implement the site's policy. In the first sentence of section 3.2, "At many sites" is unsubstantiated and unnecessary. Change the paragraph to: [-At many sites, the difficulties with distributing DNS update credentials to all of the DHCP clients lead-] {+It is possible+} to [-the desire-] {+arrange+} for [-the-] DHCP servers to perform A RR updates on behalf of their clients. If a single DHCP server [-managed-] {+manages+} all of the DHCP clients at a site, it [-could-] {+can+} maintain [-some-] {+a+} database of the DNS names [-that-] it [-was managing,-] {+manages,+} and {+can+} check that database before initiating a DNS update for a client. Such a database is necessarily proprietary, however, and [-that-] {+the+} approach does not work once more than one DHCP server is deployed. Change the second paragraph of section 3.2 to: {+When multiple DHCP servers are deployed, the servers require a way to coordinate the identities of DHCP clients.+} Consider an example in which DHCP Client A boots, obtains [-a DHCP lease-] {+an IP address+} from Server S1, presenting the hostname "foo" in a Client FQDN option [4] in its DHCPREQUEST message. Server S1 updates [-its domain name,-] {+the FQDN+} "foo.org.nil", adding an A RR [-that matches Client A's lease.-] {+containing the IP address assigned to A.+} The client then moves to another subnet, served by Server S2. When Client A boots on the new subnet, Server S2 will issue it a new [-lease,-] {+IP address,+} and will attempt to add an A RR [-matching-] {+containing+} the [-new lease-] {+newly assigned IP address+} to {+the FQDN+} "foo.org.nil". At this point, without some communication mechanism which S2 can use to ask S1 (and every other DHCP server that updates the zone) about the client, S2 has no way to know whether Client A is currently associated with the domain name, or whether A is a different client configured with the same hostname. If the servers cannot distinguish between these situations, they cannot enforce the site's naming policies. The second paragraph of section 5 includes text about whether FQDNs for DHCP clients are ever resolved through DNS. The text argues against the need for any DNS updates for DHCP clients (!). Will the assertions in this text be true in the future, especially if more point-to-point applications are deployed? In deployment, this rarely if ever represents a significant problem. Most DHCP-managed hosts are rarely looked-up by name in the DNS, and the deployment of IXFR (RFC 1995 [14]) and NOTIFY (RFC 1996 [15]) can reduce the latency between updates and their visibility at secondary servers. In the third paragraph of section 5, from what principles of DNS or operational experience is this recommendation derived: "RR TTL on a DNS record added for a DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at least 10 minutes."? What about dynamic update of the TTL to match lease expiration time? What does this sentence in section 6.2 mean: "IPv6 clients will be represented by AAAA RRs; IPv4 clients by A RRs."? In the third paragraph in section 6.3.1, does the second sentence describe the only situation in whith NOERROR can be returned or is it just an example? Can the second sentence simply be dropped? If the query returns NOERROR but without an answer, the updater can conclude that the target name is in use, but that no DHCID RR is present. This indicates that some records have been configured by an administrator. In the fifth paragraph of section 6.3.1, is it truly a MUST NOT or is it up to local policy: If any other status is returned, the updater MUST NOT attempt an update. What is "confusion" in the first sentence of section 7? Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. Why does section 7 talk about authentication of DNS updates, while this document describes a procedure for avoiding name conflicts? ----- Typos: Change the last sentence section 2: Furthermore, this specification applies only to DHCP client and server [-processes:-] {+processes;+} it does not apply to other processes that initiate DNS updates. Add commas around "if ever" in the second paragraph of section 5. In the fourth paragraph of section 6.3.1, I think the citation of [4] should be replaced by [2]. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 12:17:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbL3K-0000bI-32; Thu, 26 May 2005 12:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbL3I-0000bD-Oy for dhcwg@megatron.ietf.org; Thu, 26 May 2005 12:17:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10003 for ; Thu, 26 May 2005 12:17:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbLLv-0004pq-GF for dhcwg@ietf.org; Thu, 26 May 2005 12:36:59 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 May 2005 12:17:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4QGHO54017393 for ; Thu, 26 May 2005 12:17:33 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 12:17:27 -0400 Received: from 10.86.240.1 ([10.86.240.1]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 16:17:27 +0000 Received: from localhost.localdomain by email.cisco.com; 26 May 2005 12:17:57 -0400 Subject: Re: [dhcwg] dhc WG last call on From: Ralph Droms To: dhcwg@ietf.org In-Reply-To: <1117061216.5398.31.camel@localhost.localdomain> References: <1117061216.5398.31.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 26 May 2005 12:17:56 -0400 Message-Id: <1117124276.6323.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 26 May 2005 16:17:27.0830 (UTC) FILETIME=[68DCEB60:01C5620E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (Correction to suggested abstract) The Abstract is not clear and does not accurately reflect the intent and the contents of the doc. I suggest: Abstract DHCP provides a mechanism for host configuration that includes dynamic assignment of IP addresses. To maintain accurate name to IP address and IP address to name mappings in the DNS, these dynamically assigned addresses require updates to the DNS. Conflicts may arise between updates to the DNS from different sources. This document describes techniques for the resolution of DNS name conflicts arising from updates to the DNS to reflect dynamic IP address assignment. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 12:39:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLON-00042W-Cl; Thu, 26 May 2005 12:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLOM-00042O-HP for dhcwg@megatron.ietf.org; Thu, 26 May 2005 12:39:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11356 for ; Thu, 26 May 2005 12:39:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbLgz-0005MU-5I for dhcwg@ietf.org; Thu, 26 May 2005 12:58:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 May 2005 12:39:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4QGdG4w024948 for ; Thu, 26 May 2005 12:39:18 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 12:37:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on Date: Thu, 26 May 2005 12:37:54 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338AFC@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] dhc WG last call on Thread-Index: AcViDtZ9ej8uuWW3QpyN7kToiOeTAgAAKwZA From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , X-OriginalArrivalTime: 26 May 2005 16:37:54.0763 (UTC) FILETIME=[442C09B0:01C56211] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph: I can certainly revise the abstract but I think we also need to be careful to limit this to DHCP clients/servers as the DHCID RR is only for DHCP? How about: DHCP provides a mechanism for host configuration that includes dynamic assignment of IP addresses. To maintain accurate name to IP address and IP address to name mappings in the DNS, these dynamically assigned addresses require updates to the DNS. Conflicts may arise in the DNS names assigned to clients. This document describes technqiues for the resolution of DNS name conflicts arising from updates to the DNS by DHCP servers and/or DHCP clients to reflect dynamic IP address assignment. Another possibility would be to take some of the text from the Introduction (such as the second half o the first paragraph) and rework this into an Abstract. This would also connect this document more closely with the FQDN option and DHCID RR in the Abstract which is likely a good thing? DHCP provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name to IP address and IP address to name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients, and describes a strategy for the use of the DHCID DNS resource record in resolving those conflicts. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms (rdroms) > Sent: Thursday, May 26, 2005 12:18 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhc WG last call=20 > on >=20 > (Correction to suggested abstract) >=20 > The Abstract is not clear and does not accurately reflect the intent > and the contents of the doc. I suggest: >=20 > Abstract >=20 > DHCP provides a mechanism for host configuration that includes > dynamic assignment of IP addresses. To maintain accurate=20 > name to IP > address and IP address to name mappings in the DNS, these > dynamically assigned addresses require updates to the DNS. > Conflicts may arise between updates to the DNS from different > sources. This document describes techniques for the resolution of > DNS name conflicts arising from updates to the DNS to reflect > dynamic IP address assignment. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 13:00:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLiX-0007rR-MN; Thu, 26 May 2005 13:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLiV-0007rM-Cc for dhcwg@megatron.ietf.org; Thu, 26 May 2005 13:00:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13178 for ; Thu, 26 May 2005 13:00:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbM18-0005wp-BS for dhcwg@ietf.org; Thu, 26 May 2005 13:19:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 May 2005 10:00:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4QGxsc4006226 for ; Thu, 26 May 2005 10:00:04 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 12:59:53 -0400 Received: from 10.86.240.133 ([10.86.240.133]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 16:59:53 +0000 Received: from localhost.localdomain by email.cisco.com; 26 May 2005 13:00:22 -0400 Subject: RE: [dhcwg] dhc WG last call on From: Ralph Droms To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB21338AFC@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338AFC@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 26 May 2005 13:00:16 -0400 Message-Id: <1117126816.7913.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 26 May 2005 16:59:53.0880 (UTC) FILETIME=[566D5180:01C56214] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie - I like your second draft Abstract... - Ralph On Thu, 2005-05-26 at 12:37 -0400, Bernie Volz (volz) wrote: > Ralph: > > I can certainly revise the abstract but I think we also need to be > careful to limit this to DHCP clients/servers as the DHCID RR is only > for DHCP? How about: > > DHCP provides a mechanism for host configuration that includes > dynamic assignment of IP addresses. To maintain accurate name > to IP address and IP address to name mappings in the DNS, these > dynamically assigned addresses require updates to the DNS. > Conflicts may arise in the DNS names assigned to clients. This > document describes technqiues for the resolution of DNS name > conflicts arising from updates to the DNS by DHCP servers and/or > DHCP clients to reflect dynamic IP address assignment. > > Another possibility would be to take some of the text from the > Introduction (such as the second half o the first paragraph) and rework > this into an Abstract. This would also connect this document more > closely with the FQDN option and DHCID RR in the Abstract which is > likely a good thing? > > DHCP provides a mechanism for host configuration that includes > dynamic assignment of IP addresses and fully qualified domain > names. To maintain accurate name to IP address and IP address to > name mappings in the DNS, these dynamically assigned addresses > and fully qualified domain names require updates to the DNS. > This document identifies situations in which conflicts > in the use of fully qualified domain names may arise among DHCP > clients, and describes a strategy for the use of the DHCID DNS > resource record in resolving those conflicts. > > - Bernie > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ralph Droms (rdroms) > > Sent: Thursday, May 26, 2005 12:18 PM > > To: dhcwg@ietf.org > > Subject: Re: [dhcwg] dhc WG last call > > on > > > > (Correction to suggested abstract) > > > > The Abstract is not clear and does not accurately reflect the intent > > and the contents of the doc. I suggest: > > > > Abstract > > > > DHCP provides a mechanism for host configuration that includes > > dynamic assignment of IP addresses. To maintain accurate > > name to IP > > address and IP address to name mappings in the DNS, these > > dynamically assigned addresses require updates to the DNS. > > Conflicts may arise between updates to the DNS from different > > sources. This document describes techniques for the resolution of > > DNS name conflicts arising from updates to the DNS to reflect > > dynamic IP address assignment. > > > > _______________________________________________ > > 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-bounces@ietf.org Thu May 26 15:46:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOJU-0001Qy-Vk; Thu, 26 May 2005 15:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOJH-0001Pa-66; Thu, 26 May 2005 15:46:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27069; Thu, 26 May 2005 15:46:25 -0400 (EDT) Message-Id: <200505261946.PAA27069@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 26 May 2005 15:46:24 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-ipsec-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@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 : Authentication of DHCP Relay Agent Options Using IPsec Author(s) : R. Droms Filename : draft-ietf-dhc-relay-agent-ipsec-02.txt Pages : 10 Date : 2005-5-26 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines a mechanism for securing the messages exchanged between a relay agent and a server using IPsec (RFC 2401) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-ipsec-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-relay-agent-ipsec-02.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-relay-agent-ipsec-02.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: <2005-5-26161654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-ipsec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-ipsec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-26161654.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu May 26 16:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPJB-0001my-6l; Thu, 26 May 2005 16:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPJ6-0001mV-8n; Thu, 26 May 2005 16:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11133; Thu, 26 May 2005 16:50:17 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPbk-0006Hs-12; Thu, 26 May 2005 17:09:37 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 9635E20000E4; Thu, 26 May 2005 16:50:06 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 16:50:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 16:49:59 -0400 Message-ID: <936A4045C332714F975800409DE0924054128C@tayexc14.americas.cpqcorp.net> Thread-Topic: purpose of m/o bit Thread-Index: AcViJZrZbVZh1Iq9RIeySOTtnwFl+wABa2/AAAIQ1eA= From: "Bound, Jim" To: "da Silva, Ron" , , , , "Thomas Narten" , "Williams, Chris" X-OriginalArrivalTime: 26 May 2005 20:50:01.0231 (UTC) FILETIME=[7C3FE1F0:01C56234] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ron,=20 Thanks for doing this and this permits us to discuss it simply :--). Response on your matrix via my interpretation as implementer, no comment on your needs and appreciate you sharing that here big time, I find it very useful. Thanks. > There are nine scenarios, right? >=20 > 1) RA w/auto-conf, M off, O off Stateful is not being requested by the site or admin. No requirement to use it. > 2) RA w/auto-conf, M on, O off use stateful and other configurations available. > 3) RA w/auto-conf, M off, O on use other configurations only. =20 > 4) RA w/auto-conf, M on, O on Same as #2 is my view. > 5) RA w/o auto-conf, M off, O off > 6) RA w/o auto-conf, M on, O off > 7) RA w/o auto-conf, M off, O on > 8) RA w/o auto-conf, M on, O on My read is if auto-conf off then these bits are invalid and stateless is default. > 9) No RA Your lost and not connected have it your way :--) Use link-local :--) thanks /jim >=20 > >From a cable deployment perspective, I would expect... >=20 > 1) CM stateless auto-conf from advertised route(s) > 2) CM stateless auto-conf from advertised route(s) plus DHCPv6 for > additional address(es) > 3) CM stateless auto-conf from advertised route(s) plus DHCPv6 for > addition info > 4) CM stateless auto-conf from advertised route(s) plus DHCPv6 for > additional address(es) and additional info > 5) same behavior as #9 below ? > 6) DHCPv6 for address(es) only > 7) DHCPv6 for additional info only > 8) DHCPv6 for address(es) and additional info > 9) CM stateless auto-conf link local address followed by DHCPv6 for > additional address(es) and/or other info (same behavior as #5) >=20 > This seems way to complicated though, and it would be much more > deterministic for a CM to simply do #4 in all cases which=20 > would make the > M/O bits useless. >=20 > -ron >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 17:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPm3-00085t-8h; Thu, 26 May 2005 17:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOuL-0004WP-Na; Thu, 26 May 2005 16:24:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08948; Thu, 26 May 2005 16:24:43 -0400 (EDT) Received: from rrmail4.va.rr.com ([24.30.218.96] helo=rrmailer.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPCz-0005a5-Mw; Thu, 26 May 2005 16:44:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 16:24:31 -0400 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> Thread-Topic: purpose of m/o bit Thread-Index: AcViJZrZbVZh1Iq9RIeySOTtnwFl+wABa2/A From: "da Silva, Ron" To: , , , "Thomas Narten" , "Williams, Chris" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 May 2005 17:20:13 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org There are nine scenarios, right? 1) RA w/auto-conf, M off, O off 2) RA w/auto-conf, M on, O off 3) RA w/auto-conf, M off, O on 4) RA w/auto-conf, M on, O on 5) RA w/o auto-conf, M off, O off 6) RA w/o auto-conf, M on, O off 7) RA w/o auto-conf, M off, O on 8) RA w/o auto-conf, M on, O on 9) No RA >From a cable deployment perspective, I would expect... 1) CM stateless auto-conf from advertised route(s) 2) CM stateless auto-conf from advertised route(s) plus DHCPv6 for additional address(es) 3) CM stateless auto-conf from advertised route(s) plus DHCPv6 for addition info 4) CM stateless auto-conf from advertised route(s) plus DHCPv6 for additional address(es) and additional info 5) same behavior as #9 below ? 6) DHCPv6 for address(es) only 7) DHCPv6 for additional info only 8) DHCPv6 for address(es) and additional info 9) CM stateless auto-conf link local address followed by DHCPv6 for additional address(es) and/or other info (same behavior as #5) This seems way to complicated though, and it would be much more deterministic for a CM to simply do #4 in all cases which would make the M/O bits useless. -ron _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 17:34:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPzd-0002La-7Y; Thu, 26 May 2005 17:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPzb-0002LP-Dr; Thu, 26 May 2005 17:34:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14750; Thu, 26 May 2005 17:34:12 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbQIF-0007YC-J8; Thu, 26 May 2005 17:53:33 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4QLYFmJ098390 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 26 May 2005 23:34:16 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 26 May 2005 23:34:04 +0200 To: "da Silva, Ron" X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 26-mei-2005, at 22:24, da Silva, Ron wrote: > This seems way to complicated though, and it would be much more > deterministic for a CM to simply do #4 in all cases which would > make the > M/O bits useless. You know what's really deterministic? Manual configuration. There is a baby in this bath water... The problem with having different bits indicate different capabilities is that you get lots of permutations. So when a significant number of those don't make sense, having individual bits probably isn't the right choice. To me, assuming the current specs, the following would make sense: Configured for always-full-DHCPv6 on this interface? -> yes -> do full DHCPv6 | no | Timeout waiting for RAs? -> yes -> do full DHCPv6 | no | M bit set or no prefixes with AAC set? -> yes -> do full DHCPv6 | no | O bit set or always-stateless-DHCPv6 on this if? -> yes -> stateless DHCPv6 A stateless DHCPv6-only client would probably just look at the O bit and not do stateless DHCPv6 if just the M bit is set. Anyone believe that, with current knowledge and experience, implementing the above would be a bad idea? Please realize that even if something isn't useful in _your_ use case, that doesn't mean it's never useful. It's very important that people can open up their laptops, PDAs, smartphones and whathever, and it can talk to the local network _without_ _special_ _configuration_. I.e., I want to be able to bring my laptop to work where DHCPv6 is the only game in town, check my mail using a public hotspot over coffee with just stateless autoconfig and then go home and connect to my broadband connection using whatever comes out of the wall. And all this without having to change any settings. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 26 19:05:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRPk-0001iz-W0; Thu, 26 May 2005 19:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRPi-0001hI-DZ; Thu, 26 May 2005 19:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22266; Thu, 26 May 2005 19:05:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbRiM-0001KH-Ij; Thu, 26 May 2005 19:24:37 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 May 2005 16:05:06 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4QN4ic6010188; Thu, 26 May 2005 16:05:03 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 19:05:01 -0400 Received: from 10.86.240.133 ([10.86.240.133]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 May 2005 23:05:00 +0000 Received: from localhost.localdomain by email.cisco.com; 26 May 2005 19:05:30 -0400 From: Ralph Droms To: dhcwg@ietf.org, IETF IPv6 Mailing List In-Reply-To: References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 26 May 2005 19:05:29 -0400 Message-Id: <1117148729.7913.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 26 May 2005 23:05:01.0361 (UTC) FILETIME=[584DA210:01C56247] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Seems to me I'm hearing two requirements out of this thread: 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange - if a host wants HCB, it sends an HCB request (Solicit) and receives HCB and/or ICB replies - if a host wants ICB, it sends an ICB request (Information-request) and receives ICB replies 1 is a requirement in scenarios with limited resources (e.g., wireless), where polling for DHCP is unacceptable. 2 is a requirement to avoid timeout delays or other complexity in getting ICB reply when host would prefer HCB reply. If I've got that right, we can meet the two requirements with a couple of small updates to existing specs: 1) If an RA is received with the M and/or the O bit is set, DHCP service is available over the link through which the RA was received (no differentiation between HCB and ICB DHCP) 2) If a DHCP server receives an HCB request (Solicit) but can only supply an ICB, the server can respond with the ICB reply (note that according RFC 3115, the server would respond with an "HCB-nak" [Advertise containing only an error code]) In addition to meeting the requirements, these updates are mostly (if not entirely) operationally compatible with existing clients and servers. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 08:46:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeE3-0005xw-NX; Fri, 27 May 2005 08:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeDy-0005w3-QC; Fri, 27 May 2005 08:46:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06945; Fri, 27 May 2005 08:46:01 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbeWl-0001tN-4J; Fri, 27 May 2005 09:05:28 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 13:45:50 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 May 2005 13:45:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 13:41:34 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A700F24D9E2@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: purpose of m/o bit Thread-Index: AcViR4lYtZM4t8WYQFKqxQUEvGp5oAAcSjlQ To: , , X-OriginalArrivalTime: 27 May 2005 12:45:50.0334 (UTC) FILETIME=[02FA89E0:01C562BA] X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph Droms wrote: > Seems to me I'm hearing two requirements out of this thread: >=20 > 1) Ability to indicate to a host "DHCP is not available on this link", > with the expectation that the host won't send any DHCP messages >=20 > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) > and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request > (Information-request) > and receives ICB replies >=20 > 1 is a requirement in scenarios with limited resources (e.g., > wireless), where polling for DHCP is unacceptable. 2 is a > requirement to avoid timeout delays or other complexity in getting > ICB reply when=20 > host would > prefer HCB reply. >=20 > If I've got that right, we can meet the two requirements with a couple > of small updates to existing specs: >=20 > 1) If an RA is received with the M and/or the O bit is set, DHCP > service is available over the link through which the RA > was received > (no differentiation between HCB and ICB DHCP) >=20 > 2) If a DHCP server receives an HCB request (Solicit) but can only > supply an ICB, the server can respond with the ICB reply (note that > according RFC 3115, the server would respond with an "HCB-nak" > [Advertise containing only an error code]) >=20 > In addition to meeting the requirements, these updates are mostly (if > not entirely) operationally compatible with existing clients and > servers.=20 I completely agree with this analysis and support proceeding on this basis. But it does beg the question, why do we need two bits to signal a binary condition? -- Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 08:57:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeOi-00080h-KR; Fri, 27 May 2005 08:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeOa-0007xX-Bv; Fri, 27 May 2005 08:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07615; Fri, 27 May 2005 08:56:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbehO-00027o-0D; Fri, 27 May 2005 09:16:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 08:56:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RCuUlM002666; Fri, 27 May 2005 08:56:48 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 08:56:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 08:56:27 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338C91@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViR4lYtZM4t8WYQFKqxQUEvGp5oAAcSjlQAACA9iA= From: "Bernie Volz \(volz\)" To: , "Ralph Droms \(rdroms\)" , , X-OriginalArrivalTime: 27 May 2005 12:56:28.0809 (UTC) FILETIME=[7F8A1790:01C562BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org We don't but it avoids issues with backwards compatibility (though I don't believe that is a big issue yet). I think if we come to agreement on having no distinction between the bits, we should deprecate one of the bits (O-bit?); though for backwards compatibility, we can't remove/reassign it until many years from now (if ever). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of matthew.ford@bt.com > Sent: Friday, May 27, 2005 8:42 AM > To: Ralph Droms (rdroms); dhcwg@ietf.org; ipv6@ietf.org > Subject: [dhcwg] RE: purpose of m/o bit >=20 > Ralph Droms wrote: >=20 > > Seems to me I'm hearing two requirements out of this thread: > >=20 > > 1) Ability to indicate to a host "DHCP is not available on=20 > this link", > > with the expectation that the host won't send any DHCP messages > >=20 > > 2) Ability for a host to get all desired and available DHCP > > configuration with a single DHCP message exchange > > - if a host wants HCB, it sends an HCB request (Solicit) > > and receives > > HCB and/or ICB replies > > - if a host wants ICB, it sends an ICB request > > (Information-request) > > and receives ICB replies > >=20 > > 1 is a requirement in scenarios with limited resources (e.g., > > wireless), where polling for DHCP is unacceptable. 2 is a > > requirement to avoid timeout delays or other complexity in getting > > ICB reply when=20 > > host would > > prefer HCB reply. > >=20 > > If I've got that right, we can meet the two requirements=20 > with a couple > > of small updates to existing specs: > >=20 > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > service is available over the link through which the RA > > was received > > (no differentiation between HCB and ICB DHCP) > >=20 > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > supply an ICB, the server can respond with the ICB reply=20 > (note that > > according RFC 3115, the server would respond with an "HCB-nak" > > [Advertise containing only an error code]) > >=20 > > In addition to meeting the requirements, these updates are=20 > mostly (if > > not entirely) operationally compatible with existing clients and > > servers.=20 >=20 > I completely agree with this analysis and support proceeding on this > basis. But it does beg the question, why do we need two bits=20 > to signal a > binary condition? >=20 > -- Mat >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 08:59:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeQZ-0008Jv-1X; Fri, 27 May 2005 08:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeQS-0008Ie-4m; Fri, 27 May 2005 08:58:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07695; Fri, 27 May 2005 08:58:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbejE-0002Aw-Nq; Fri, 27 May 2005 09:18:22 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 08:58:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RCwgl6003220; Fri, 27 May 2005 08:58:42 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 08:58:40 -0400 Received: from 10.86.240.133 ([10.86.240.133]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 12:58:39 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 08:59:09 -0400 From: Ralph Droms To: matthew.ford@bt.com In-Reply-To: <0AAF93247C75E3408638B965DEE11A700F24D9E2@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A700F24D9E2@i2km41-ukdy.domain1.systemhost.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 08:59:08 -0400 Message-Id: <1117198748.7913.79.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 12:58:40.0275 (UTC) FILETIME=[CDE63630:01C562BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Mat - thanks for your review and input. I specified the two bits only for backward compatibility with existing implementations. I imagine we could design a specification that retains one bit and deprecates the other, with rules about the appearance of the depre backward compatibility. At least, this spec would need a note explaining why there are two bits in the spec and recommending that new implementations use, for example, just the M bit. - Ralph On Fri, 2005-05-27 at 13:41 +0100, matthew.ford@bt.com wrote: > Ralph Droms wrote: > > > Seems to me I'm hearing two requirements out of this thread: > > > > 1) Ability to indicate to a host "DHCP is not available on this link", > > with the expectation that the host won't send any DHCP messages > > > > 2) Ability for a host to get all desired and available DHCP > > configuration with a single DHCP message exchange > > - if a host wants HCB, it sends an HCB request (Solicit) > > and receives > > HCB and/or ICB replies > > - if a host wants ICB, it sends an ICB request > > (Information-request) > > and receives ICB replies > > > > 1 is a requirement in scenarios with limited resources (e.g., > > wireless), where polling for DHCP is unacceptable. 2 is a > > requirement to avoid timeout delays or other complexity in getting > > ICB reply when > > host would > > prefer HCB reply. > > > > If I've got that right, we can meet the two requirements with a couple > > of small updates to existing specs: > > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > service is available over the link through which the RA > > was received > > (no differentiation between HCB and ICB DHCP) > > > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > supply an ICB, the server can respond with the ICB reply (note that > > according RFC 3115, the server would respond with an "HCB-nak" > > [Advertise containing only an error code]) > > > > In addition to meeting the requirements, these updates are mostly (if > > not entirely) operationally compatible with existing clients and > > servers. > > I completely agree with this analysis and support proceeding on this > basis. But it does beg the question, why do we need two bits to signal a > binary condition? > > -- Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 09:02:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeUN-0000ZZ-Sp; Fri, 27 May 2005 09:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeUM-0000ZR-46 for dhcwg@megatron.ietf.org; Fri, 27 May 2005 09:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08123 for ; Fri, 27 May 2005 09:02:56 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dben8-0002Hy-AQ for dhcwg@ietf.org; Fri, 27 May 2005 09:22:24 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:02:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RD2hl8005011 for ; Fri, 27 May 2005 09:02:45 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:02:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on Date: Fri, 27 May 2005 09:02:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338C95@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] dhc WG last call on Thread-Index: AcViDPPRWrn9FVCwQZ6DdB9HV5BfFAArwF8g From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , X-OriginalArrivalTime: 27 May 2005 13:02:26.0195 (UTC) FILETIME=[548EDE30:01C562BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks for the extensive feedback. I haven't yet reviewed all of the comments in depth, but they seem very appropriate. I think I'll wait to see if any other comments appear over the WG Last Call and then respin the draft with these revisions (and the new abstract discussed separately). - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms (rdroms) > Sent: Thursday, May 26, 2005 12:02 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhc WG last call=20 > on >=20 > In general, I think the mechanism specified in this document is fully > baked and useful. >=20 > I do have some substantive comments and many editorial comments: >=20 >=20 > Substantive comments: >=20 > The Terminology section should have a list of acronyms and terms used > in the doc; e.g., FQDN, Name Conflict, MCNS >=20 > The Abstract is not clear and does not accurately reflect the intent > and the contents of the doc. I suggest: >=20 > Abstract >=20 > DHCP provides a mechanism for host configuration that includes > dynamic assignment of IP addresses. To maintain accurate IP > address and IP address to name mappings in the DNS, these > dynamically assigned addresses require updates to the DNS. > Conflicts may arise between updates to the DNS from different > sources. This document describes techniques for the resolution of > DNS name conflicts arising from updates to the DNS to reflect > dynamic IP address assignment. >=20 > I read the last sentence of the first paragraph of 3.1 to imply that > Secure DNS can mitigate the problem of name conflicts. Can Secure DNS > mitigate or preclude name conflicts; I'm not sure it has any effect on > name conflicts: >=20 > Sites that > deploy Secure DNS [10] may configure credentials for each host and > its assigned name in a way that is more -error-resistant, but this > level of pre-configuration is still rare in DHCP environments. >=20 > I knew to look for it, but found that the explanation in > draft-ietf-dnsext-dhcid-rr of how to use the new style of IPv4 client > identifier defined in draft-ietf-dhc-3315id-for-v4 is obscure. I > think it would be good, perhaps in a DISCUSSION, to point out that the > use of 3315id-for-v4 identifiers leads to exactly the same data in the > DHCID RR, because the DUID portion is encoded as an IPv6-style > identifier. >=20 > In the update mechanisms in section 6.3.2, is it possible for both the > A and AAA RRs to be updated simultaneously? The text seems to refer > to "A or AAAA" throughout section 6. >=20 > What does "perform some name disambiguation operation on behalf of the > current client" in the first paragraph of section 6.3.4 mean? >=20 > Is there any possibility of a name conflict related to PTR records > (section 6.4)? >=20 > ----- > Editorial comments: >=20 > The term "lease" is often used where the terms "IP address" or > "assigned IP address" would be more precise. >=20 > "DNS name", "domain name" and "FQDN" are used interchangeably > throughout the doc. For consistency, choose one term - I would > recommend FQDN - and use it throughout. >=20 > A and AAAA RRs are not mutually exclusive. The text should be edited > to reflect that a client may have both A and AAAA RRs simultaneously. > For example, in the first paragraph of section 2, change the third > sentence: >=20 > Through the use of the client FQDN option, DHCP clients and servers > can negotiate the client's FQDN and the allocation of > responsibility for updating the DHCP client's A [-or-] {+and+} AAAA > [-RR.-] {+RRs.+} >=20 > Both clients and servers can experience name conflicts. Change the > last sentence of the first paragraph of section 2: >=20 > This document identifies situations in which conflicts in the use > of FQDNs may arise among DHCP [-clients,-] {+clients and servers,+} > and describes a strategy for the use of the DHCID DNS resource > record [2] in resolving those conflicts. >=20 > The term "Name Conflict" is defined in the first paragraph of section > 3 but not used anywhere else in the document (except in the title). > Drop the definition? >=20 > Change the first two sentences of section 3.1: >=20 > [-At many (though not all) sites, administrators-] {+Administrators > may+} wish to maintain a one-to-one relationship between active > DHCP clients and domain names, and to maintain consistency between > a host's [-A-] {+A, AAAA+} and PTR RRs. Hosts that are not > represented in the DNS, or hosts [-which-] {+that+} inadvertently > share an FQDN with another host may encounter inconsistent behavior > or may not be able to obtain access to network resources. >=20 > Change the last sentence of the first paragraph of section 3.1: >=20 > Sites that deploy Secure DNS [10] may configure credentials for > each host and its assigned name in a way that is more > [-error-resistant, but this level of pre-configuration is still > rare in DHCP environments.-] {+error-resistant.+} >=20 > Change the last paragraph on page 4 (includes examples of replacing > "lease" with the more precise "IP address" or "assigned IP address"): >=20 > If the policy is that the first DHCP client with a given name > should be the only client associated with that name, Client B needs > to be able to determine [-that-] {+whether or not+} it is not the > client associated with "foo.org.nil". It could be that Client A > booted first, and that Client B should choose another name. Or it > could be that B has booted on a new subnet, and received a new > [-lease.-] {+IP address, in which case B should update the DNS with > its new IP address.+} It must either retain persistent state about > the last [-lease-] {+IP address+} it [-held-] {+was assigned+} (in > addition to its current [-lease)-] {+IP address)+} or it must have > some other way to detect that it was the last updater of > "foo.org.nil" in order to implement the site's policy. >=20 > In the first sentence of section 3.2, "At many sites" is > unsubstantiated and unnecessary. Change the paragraph to: >=20 > [-At many sites, the difficulties with distributing DNS update > credentials to all of the DHCP clients lead-] {+It is possible+} to > [-the desire-] {+arrange+} for [-the-] DHCP servers to perform A RR > updates on behalf of their clients. If a single DHCP server > [-managed-] {+manages+} all of the DHCP clients at a site, it > [-could-] {+can+} maintain [-some-] {+a+} database of the DNS names > [-that-] it [-was managing,-] {+manages,+} and {+can+} check that > database before initiating a DNS update for a client. Such a > database is necessarily proprietary, however, and [-that-] {+the+} > approach does not work once more than one DHCP server is deployed. >=20 > Change the second paragraph of section 3.2 to: >=20 > {+When multiple DHCP servers are deployed, the servers require a > way to coordinate the identities of DHCP clients.+} Consider an > example in which DHCP Client A boots, obtains [-a DHCP lease-] {+an > IP address+} from Server S1, presenting the hostname "foo" in a > Client FQDN option [4] in its DHCPREQUEST message. Server S1 > updates [-its domain name,-] {+the FQDN+} "foo.org.nil", adding an > A RR [-that matches Client A's lease.-] {+containing the IP address > assigned to A.+} The client then moves to another subnet, served by > Server S2. When Client A boots on the new subnet, Server S2 will > issue it a new [-lease,-] {+IP address,+} and will attempt to add > an A RR [-matching-] {+containing+} the [-new lease-] {+newly > assigned IP address+} to {+the FQDN+} "foo.org.nil". At this > point, without some communication mechanism which S2 can use to ask > S1 (and every other DHCP server that updates the zone) about the > client, S2 has no way to know whether Client A is currently > associated with the domain name, or whether A is a different client > configured with the same hostname. If the servers cannot > distinguish between these situations, they cannot enforce the > site's naming policies. >=20 > The second paragraph of section 5 includes text about whether FQDNs > for DHCP clients are ever resolved through DNS. The text argues > against the need for any DNS updates for DHCP clients (!). Will the > assertions in this text be true in the future, especially if more > point-to-point applications are deployed? >=20 > In deployment, this rarely if ever represents a > significant problem. Most DHCP-managed hosts are rarely=20 > looked-up by > name in the DNS, and the deployment of IXFR (RFC 1995 [14]) and > NOTIFY (RFC 1996 [15]) can reduce the latency between updates and > their visibility at secondary servers. >=20 > In the third paragraph of section 5, from what principles of DNS or > operational experience is this recommendation derived: "RR TTL on a > DNS record added for a DHCP lease SHOULD NOT exceed 1/3 of the lease > time, and SHOULD be at least 10 minutes."? What about dynamic update > of the TTL to match lease expiration time? >=20 > What does this sentence in section 6.2 mean: "IPv6 clients will be > represented by AAAA RRs; IPv4 clients by A RRs."? >=20 > In the third paragraph in section 6.3.1, does the second sentence > describe the only situation in whith NOERROR can be returned or is it > just an example? Can the second sentence simply be dropped? >=20 > If the query returns NOERROR but without an answer, the updater can > conclude that the target name is in use, but that no DHCID RR is > present. This indicates that some records have been configured by > an administrator. >=20 > In the fifth paragraph of section 6.3.1, is it truly a MUST NOT or is > it up to local policy: >=20 > If any other status is returned, the updater MUST NOT attempt an > update. >=20 > What is "confusion" in the first sentence of section 7? >=20 > Unauthenticated updates to the DNS can lead to tremendous > confusion, through malicious attack or through inadvertent > misconfiguration. >=20 > Why does section 7 talk about authentication of DNS updates, while > this document describes a procedure for avoiding name conflicts? >=20 > ----- > Typos: >=20 > Change the last sentence section 2: >=20 > Furthermore, this specification applies only to DHCP client and > server [-processes:-] {+processes;+} it does not apply to other > processes that initiate DNS updates. >=20 > Add commas around "if ever" in the second paragraph of section 5. >=20 > In the fourth paragraph of section 6.3.1, I think the citation of [4] > should be replaced by [2]. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 09:07:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeYu-00020M-4K; Fri, 27 May 2005 09:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeYr-0001vg-EJ; Fri, 27 May 2005 09:07:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08690; Fri, 27 May 2005 09:07:36 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbere-0002TN-6R; Fri, 27 May 2005 09:27:03 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RD7cmJ009903 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 15:07:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338C91@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338C91@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66D05231-EE27-4AF9-B197-D4E50AA35C86@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 15:07:20 +0200 To: Bernie Volz ((volz)) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote: > I think if we come to agreement on having no distinction between the > bits, we should deprecate one of the bits (O-bit?); though for > backwards > compatibility, we can't remove/reassign it until many years from > now (if > ever). I think having M = 0, O = 1 would be useful as an indication that clients should use the simplified stateless DHCPv6 rather than the full DHCPv6. And I would object to any deprecation on the basis that there isn't enough operational experience to be able to make a good decision. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 09:19:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbejs-0005fQ-SX; Fri, 27 May 2005 09:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbejp-0005eZ-Dk; Fri, 27 May 2005 09:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09636; Fri, 27 May 2005 09:18:56 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbf2c-0002mS-8A; Fri, 27 May 2005 09:38:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:18:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDI95I014281; Fri, 27 May 2005 09:18:44 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:18:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 09:18:14 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVivR4fj/53Kf3FRE61JK+gHvwwhgAAGKFA From: "Bernie Volz \(volz\)" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 13:18:15.0220 (UTC) FILETIME=[8A389740:01C562BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Why? If we update the DHCPv6 protocol to allow "other configuration" options to be returned in an Advertise for a Solicit, Information-Request/Reply and Solicit/Advertise are then essentially the same in a stateless DHCPv6 environment (though the Solicit does require a client identifier and likely may require a IA_* option). Note that this will require changes to 3315 and 3736 - since stateless servers will need to respond to Solicits with Advertises. Clients that can do full 3315, would. And, if no stateful DHCPv6 server is available but a stateless is, it will get "other configuration parameters". Clients that only do 3736 would do that and get "other configuration parameters". I think if we have two bits, we'll just be back to some of the edge conditions (what if M is set, but O isn't, etc). These changes would potentially cause some issues with any deployments today because the clients and servers do not support this "new" behavior, but it that's why it is critical we work this out ASAP. However, those clients, if they use the M & O bits, could continue to do what they do today -- since both bits are available. It is just new clients with old servers that may have issues. - Bernie > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Friday, May 27, 2005 9:07 AM > To: Bernie Volz (volz) > Cc: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote: >=20 > > I think if we come to agreement on having no distinction between the > > bits, we should deprecate one of the bits (O-bit?); though for =20 > > backwards > > compatibility, we can't remove/reassign it until many years from =20 > > now (if > > ever). >=20 > I think having M =3D 0, O =3D 1 would be useful as an indication that = > clients should use the simplified stateless DHCPv6 rather than the =20 > full DHCPv6. >=20 > And I would object to any deprecation on the basis that there isn't =20 > enough operational experience to be able to make a good decision. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 09:30:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbevP-0008QL-3S; Fri, 27 May 2005 09:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbevN-0008QD-QJ; Fri, 27 May 2005 09:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10512; Fri, 27 May 2005 09:30:50 -0400 (EDT) Received: from rrmail4.va.rr.com ([24.30.218.96] helo=rrmailer.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfE8-00035C-QY; Fri, 27 May 2005 09:50:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 09:30:37 -0400 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> Thread-Topic: purpose of m/o bit Thread-Index: AcViOrBwWse2g8nwRhSHR30WE/CGagAhP9+Q From: "da Silva, Ron" To: "Iljitsch van Beijnum" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > To me, assuming the current specs, the following would make sense: One of the permutations missing in your algorithm is if a device is configured for always-full-DHCPv6 on an interface AND it receives RA with AAC set...I presume in that case the device would get multiple addresses, right? -ron _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 09:44:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbf8f-0002tC-Hh; Fri, 27 May 2005 09:44:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbf8c-0002sX-Lj; Fri, 27 May 2005 09:44:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11312; Fri, 27 May 2005 09:44:33 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfRP-0003LN-JR; Fri, 27 May 2005 10:04:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 May 2005 06:44:22 -0700 X-IronPort-AV: i="3.93,143,1115017200"; d="scan'208"; a="270483785:sNHT31067240" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDhZmQ019164; Fri, 27 May 2005 06:44:16 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:44:13 -0400 Received: from 10.86.240.133 ([10.86.240.133]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 13:44:13 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 09:44:42 -0400 Subject: Re: [dhcwg] Re: purpose of m/o bit From: Ralph Droms To: "da Silva, Ron" In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 09:44:42 -0400 Message-Id: <1117201482.7913.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 13:44:13.0815 (UTC) FILETIME=[2B375070:01C562C2] X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ron - Use of AAC on specific prefixes advertised in RAs, as controlled by the A bit in a prefix information option, is independent of the use of DHCP ... so you're right, if there are prefixes in an RA with the A bit set, and the M and/or O bits are set in that RA, the host would configure both AAC addresses and DHCP-assigned addresses. I didn't include anything about AAC in the analysis I posted because I think they are completely independent... - Ralph On Fri, 2005-05-27 at 09:30 -0400, da Silva, Ron wrote: > > To me, assuming the current specs, the following would make sense: > > One of the permutations missing in your algorithm is if a device is > configured for always-full-DHCPv6 on an interface AND it receives RA > with AAC set...I presume in that case the device would get multiple > addresses, right? > > -ron > > _______________________________________________ > 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-bounces@ietf.org Fri May 27 09:50:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfEO-0003ba-E8; Fri, 27 May 2005 09:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfEL-0003at-9B; Fri, 27 May 2005 09:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11865; Fri, 27 May 2005 09:50:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfX8-0003Uu-8V; Fri, 27 May 2005 10:09:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:49:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDnF50023440; Fri, 27 May 2005 09:49:25 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:49:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: purpose of m/o bit Date: Fri, 27 May 2005 09:49:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338CB9@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcViOrBwWse2g8nwRhSHR30WE/CGagAhP9+QAACRCZA= From: "Bernie Volz \(volz\)" To: "da Silva, Ron" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 13:49:17.0771 (UTC) FILETIME=[E06351B0:01C562C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Depends on what the DHCPv6 server is configured to do. AAC and DHCPv6 can assign addresses on the same prefix, but I would suspect that in most deployments there is little reason to do that. Instead, DHCPv6 would likely assign addresses on prefixes that are not AAC. More likley is that you have a unique local prefix that you allow AAC for. But, for a global unicast address you need to go to DHCPv6. The DHCPv6 server would *NOT* likely assign another unique local address for that client. Just because a prefix is advertised as AAC or not, does not imply ANYTHING about what DHCPv6 would do for that prefix. Though in practice there is little reason to use both AAC and DHCPv6 on that single prefix. Though there may be good reason to do AAC on some prefixes and DHCPv6 on others if multiple prefixes are active. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of da Silva, Ron > Sent: Friday, May 27, 2005 9:31 AM > To: Iljitsch van Beijnum > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 > > To me, assuming the current specs, the following would make sense: >=20 > One of the permutations missing in your algorithm is if a device is > configured for always-full-DHCPv6 on an interface AND it receives RA > with AAC set...I presume in that case the device would get multiple > addresses, right? >=20 > -ron >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 09:52:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfG6-0003sE-Ks; Fri, 27 May 2005 09:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfG2-0003rU-Pb; Fri, 27 May 2005 09:52:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12016; Fri, 27 May 2005 09:52:13 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfYq-0003ZE-Ss; Fri, 27 May 2005 10:11:41 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:52:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDpmlI020958; Fri, 27 May 2005 09:52:01 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:52:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: purpose of m/o bit Date: Fri, 27 May 2005 09:52:00 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338CBE@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcViwsj0jKoQCvbuQneFjb54abIRlQAAFfIg From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "da Silva, Ron" X-OriginalArrivalTime: 27 May 2005 13:52:01.0082 (UTC) FILETIME=[41BA99A0:01C562C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > if there are prefixes in an RA with the A > bit set, and the M and/or O bits are set in that RA, the host would > configure both AAC addresses and DHCP-assigned addresses. That assumes that the DHCPv6 will provide addresses on that prefix. In most cases, I would suspect that is not the case. However, the DHCPv6 server would assign addresses on other prefixes. =20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms (rdroms) > Sent: Friday, May 27, 2005 9:45 AM > To: da Silva, Ron > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; IETF IPv6 Mailing List > Subject: Re: [dhcwg] Re: purpose of m/o bit >=20 > Ron - Use of AAC on specific prefixes advertised in RAs, as controlled > by the A bit in a prefix information option, is independent of the use > of DHCP ... so you're right, if there are prefixes in an RA with the A > bit set, and the M and/or O bits are set in that RA, the host would > configure both AAC addresses and DHCP-assigned addresses. >=20 > I didn't include anything about AAC in the analysis I posted because I > think they are completely independent... >=20 > - Ralph >=20 > On Fri, 2005-05-27 at 09:30 -0400, da Silva, Ron wrote: > > > To me, assuming the current specs, the following would make sense: > >=20 > > One of the permutations missing in your algorithm is if a device is > > configured for always-full-DHCPv6 on an interface AND it receives RA > > with AAC set...I presume in that case the device would get multiple > > addresses, right? > >=20 > > -ron > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 10:42:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbg2E-000822-Bn; Fri, 27 May 2005 10:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbg2C-00081T-03; Fri, 27 May 2005 10:42:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17629; Fri, 27 May 2005 10:41:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbgKz-0004mK-BT; Fri, 27 May 2005 11:01:26 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 10:41:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4REfT5C011025; Fri, 27 May 2005 10:41:47 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 10:41:46 -0400 Received: from 161.44.65.252 ([161.44.65.252]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 14:41:46 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 10:42:15 -0400 Subject: RE: [dhcwg] Re: purpose of m/o bit From: Ralph Droms To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CBE@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338CBE@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 10:42:14 -0400 Message-Id: <1117204934.9663.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 14:41:46.0342 (UTC) FILETIME=[35152060:01C562CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List , "da Silva, Ron" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I didn't mean to imply that the AAC and DHCP addresses would come from the same prefix - there's nothing that precludes such assignment; I can't think of a reason why it would be done in practice. I simply stated that the host would configure a collection of AAC addresses and DHCP-assigned addresses from the collection of prefixes available on the link. - Ralph On Fri, 2005-05-27 at 09:52 -0400, Bernie Volz (volz) wrote: > > if there are prefixes in an RA with the A > > bit set, and the M and/or O bits are set in that RA, the host would > > configure both AAC addresses and DHCP-assigned addresses. > > That assumes that the DHCPv6 will provide addresses on that prefix. In > most cases, I would suspect that is not the case. However, the DHCPv6 > server would assign addresses on other prefixes. > > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ralph Droms (rdroms) > > Sent: Friday, May 27, 2005 9:45 AM > > To: da Silva, Ron > > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; IETF IPv6 Mailing List > > Subject: Re: [dhcwg] Re: purpose of m/o bit > > > > Ron - Use of AAC on specific prefixes advertised in RAs, as controlled > > by the A bit in a prefix information option, is independent of the use > > of DHCP ... so you're right, if there are prefixes in an RA with the A > > bit set, and the M and/or O bits are set in that RA, the host would > > configure both AAC addresses and DHCP-assigned addresses. > > > > I didn't include anything about AAC in the analysis I posted because I > > think they are completely independent... > > > > - Ralph > > > > On Fri, 2005-05-27 at 09:30 -0400, da Silva, Ron wrote: > > > > To me, assuming the current specs, the following would make sense: > > > > > > One of the permutations missing in your algorithm is if a device is > > > configured for always-full-DHCPv6 on an interface AND it receives RA > > > with AAC set...I presume in that case the device would get multiple > > > addresses, right? > > > > > > -ron > > > > > > _______________________________________________ > > > 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-bounces@ietf.org Fri May 27 11:16:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbgZQ-0006km-Ky; Fri, 27 May 2005 11:16:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbgZM-0006kR-Rc; Fri, 27 May 2005 11:16:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20096; Fri, 27 May 2005 11:16:14 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbgsA-0005Yl-Pf; Fri, 27 May 2005 11:35:44 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id ABC5356870; Fri, 27 May 2005 08:16:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4AFD5C60-F460-41C8-B2D8-387A15B009FD@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 08:15:51 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote: > These changes would potentially cause some issues with any deployments > today because the clients and servers do not support this "new" > behavior, but it that's why it is critical we work this out ASAP. > However, those clients, if they use the M & O bits, could continue > to do > what they do today -- since both bits are available. It is just new > clients with old servers that may have issues. I may not have a full sense of the market, but FWIW I don't get the impression that backwards compatibility for servers is a huge issue at the moment. So a simplifying change at this point would be a good thing. There have certainly been times in the past when we've regretted our failure to make simplifying changes in the DHCP protocol back when it wasn't widely deployed. (Or at least I have - I can't really speak for other members of the wg.) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:02:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhIB-0007L8-Kg; Fri, 27 May 2005 12:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhI8-0007KS-56; Fri, 27 May 2005 12:02:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22609; Fri, 27 May 2005 12:02:29 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbhaw-0006VK-6X; Fri, 27 May 2005 12:21:59 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RG2WmJ012503 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 18:02:33 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6448C0ED-58E1-4749-9B9E-E5BE06D816E4@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 18:02:22 +0200 To: Bernie Volz ((volz)) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote: > Why? Well, why not? I'm not too familiar with the internals of DHCPv6, but I can imagine that it would be moderately useful if a client knows in advance whether it's going to do full DHCP and may receive stateful information, or it's only going to obtain some stateless information. I'm not sure if we would be designing this today that we'd include an O bit, but it's here, and using it in this way comes reasonably close to its original meaning AND may provide some benefits, so why go through the trouble of doing something radical now? > If we update the DHCPv6 protocol to allow "other configuration" > options > to be returned in an Advertise for a Solicit, Information-Request/ > Reply > and Solicit/Advertise are then essentially the same in a stateless > DHCPv6 environment (though the Solicit does require a client > identifier > and likely may require a IA_* option). So we need to do more protocol work in order to send larger packets so we can get rid of a bit that doesn't bother anyone? Hm... > I think if we have two bits, we'll just be back to some of the edge > conditions (what if M is set, but O isn't, etc). I think I addressed that in my message yesterday, for the most part. If we ignore all other input and just look at the bits, then: M O stateful clients stateless clients 0 0 do nothing do nothing 1 0 send Solicit do nothing 0 1 send Information-Request send Information-Request 1 1 send Solicit send Information-Request The compelling advantage here would be that it's possible to run a server that only understands stateless DHCPv6. (I'm assuming that you need a server that implements full DHCPv6 to answer Solicits even if it otherwise only serves up stateless information.) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:12:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhSF-0000BH-G1; Fri, 27 May 2005 12:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhSE-0000B6-4E; Fri, 27 May 2005 12:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23270; Fri, 27 May 2005 12:12:55 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbhl3-0006k2-Fd; Fri, 27 May 2005 12:32:25 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RGD3mJ012663 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 18:13:03 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BEBBF0B-D240-4347-819F-6F2F5F7EF076@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 27 May 2005 18:12:53 +0200 To: "da Silva, Ron" X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 27-mei-2005, at 15:30, da Silva, Ron wrote: > One of the permutations missing in your algorithm is if a device is > configured for always-full-DHCPv6 on an interface AND it receives RA > with AAC set...I presume in that case the device would get multiple > addresses, right? Like Ralph, I didn't include those because stateless autoconfiguration happens independent from DHCPv6. But now that you ask... Over in shim6/multi6 we're thinking about multihoming mechanisms where security is derived from "hash-based addresses": the hash over certain information is used as an interface identifier. It would be nice to be able to implement all of this in middleboxes rather than / in addition to hosts, but then we need to have a way to assign a specific address to a host. In order to provide "legacy" IPv6 connectivity we need to do stateless address autoconfig, but it would be nice if we could make the hosts in question ignore those addresses and just use the hash-based one obtained from a DHCP server. (Note that the above goes several steps further than the official wg consensus, just thinking ahead.) I guess there are two ways to do this: an ND/RA option that tells a host how to use stateless autoconfig and/or DHCP derived addresses, or a DHCPv6 option that does the same. I.e., such an option could tell the host "don't use stateless autoconfig". Thinking about this stuff, I wondered: - how does the DHCP server know which prefixes are on-link for the host? - what happens when the DHCP server assigns an address that the router doesn't recognize as on-link? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhVc-0001qV-Sj; Fri, 27 May 2005 12:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhVa-0001n5-56; Fri, 27 May 2005 12:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23962; Fri, 27 May 2005 12:16:23 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbhoO-0006vX-Ao; Fri, 27 May 2005 12:35:53 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 12:16:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RGG9l8009987; Fri, 27 May 2005 12:16:11 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:16:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:16:05 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338D2D@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi1Z44jKqEXt8rRzOjUX7fwuzm+gAADvvQ From: "Bernie Volz \(volz\)" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 16:16:06.0339 (UTC) FILETIME=[62B42130:01C562D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > 1 1 send Solicit send Information-Request But what happens if the stateful server is down and stateless is running? Though I would never recommend that a link have both of these types of servers. We could easily resolve this by adjusting the DHCPv6 protocol as proposed (ie, stateful and stateless servers can respond to Solicit with Advertise with just other configuration parameters). Then, if people feel that there is value in having the two bits, all will work. Of course, there is the issue that the stateful server is down and later returns, but I would argue that it would be a BAD idea to run BOTH a stateful and stateless server on a single link -- run ONE type or the OTHER; not both! We really want to communicate three states in terms of the DHCPv6 service available on the link: No DHCPv6, Stateful DHCPv6, and Stateless DHCPv6 -- not 4. Note that this says nothing about what a client supports (if the client can only do stateless, that's all it can do!). Clients would run DHCPv6 unless the "No DHCPv6" is set. So, perhaps we should deprecate M=3D1 *AND* O=3D1. Clients should always = run DHCPv6 if EITHER M =3D 1 OR O =3D 1. If M=3D1, run stateful (if = supported, stateless otherwise). If O=3D1, run stateless (if supported). In any case, I would still fix the DHCPv6 protocol to allow Advertises to return other configuration parameters when no addresses are available AND to require stateless DHCPv6 servers to support Solicit (with Advertise with just other configuration parameters). I still believe deprecating the 2nd bit (O) is better. - Bernie > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Friday, May 27, 2005 12:02 PM > To: Bernie Volz (volz) > Cc: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote: >=20 > > Why? >=20 > Well, why not? >=20 > I'm not too familiar with the internals of DHCPv6, but I can imagine =20 > that it would be moderately useful if a client knows in advance =20 > whether it's going to do full DHCP and may receive stateful =20 > information, or it's only going to obtain some stateless information. >=20 > I'm not sure if we would be designing this today that we'd=20 > include an =20 > O bit, but it's here, and using it in this way comes=20 > reasonably close =20 > to its original meaning AND may provide some benefits, so why go =20 > through the trouble of doing something radical now? >=20 > > If we update the DHCPv6 protocol to allow "other configuration" =20 > > options > > to be returned in an Advertise for a Solicit, Information-Request/=20 > > Reply > > and Solicit/Advertise are then essentially the same in a stateless > > DHCPv6 environment (though the Solicit does require a client =20 > > identifier > > and likely may require a IA_* option). >=20 > So we need to do more protocol work in order to send larger packets =20 > so we can get rid of a bit that doesn't bother anyone? Hm... >=20 > > I think if we have two bits, we'll just be back to some of the edge > > conditions (what if M is set, but O isn't, etc). >=20 > I think I addressed that in my message yesterday, for the most part. =20 > If we ignore all other input and just look at the bits, then: >=20 > M O stateful clients stateless clients > 0 0 do nothing do nothing > 1 0 send Solicit do nothing > 0 1 send Information-Request send Information-Request > 1 1 send Solicit send Information-Request >=20 > The compelling advantage here would be that it's possible to run a =20 > server that only understands stateless DHCPv6. (I'm assuming=20 > that you =20 > need a server that implements full DHCPv6 to answer Solicits even if =20 > it otherwise only serves up stateless information.) >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:31:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhkB-0006Xs-Hx; Fri, 27 May 2005 12:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhkA-0006Xj-JW; Fri, 27 May 2005 12:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24923; Fri, 27 May 2005 12:31:28 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi2x-0007K8-Ji; Fri, 27 May 2005 12:50:57 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id D0EA6189; Fri, 27 May 2005 12:28:51 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:30:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:30:33 -0400 Message-ID: <936A4045C332714F975800409DE092405414F6@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViR4lYtZM4t8WYQFKqxQUEvGp5oAAcSjlQAACA9iAAB6alUA== From: "Bound, Jim" To: "Bernie Volz (volz)" , , "Ralph Droms (rdroms)" , , X-OriginalArrivalTime: 27 May 2005 16:30:38.0924 (UTC) FILETIME=[6ACE08C0:01C562D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org the o bit was to state use dhcpv6 but not for addresses. it is not binary but ternary. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bernie Volz (volz) > Sent: Friday, May 27, 2005 8:56 AM > To: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > We don't but it avoids issues with backwards compatibility (though I > don't believe that is a big issue yet). >=20 > I think if we come to agreement on having no distinction between the > bits, we should deprecate one of the bits (O-bit?); though=20 > for backwards > compatibility, we can't remove/reassign it until many years=20 > from now (if > ever). >=20 > - Bernie >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > > On Behalf Of matthew.ford@bt.com > > Sent: Friday, May 27, 2005 8:42 AM > > To: Ralph Droms (rdroms); dhcwg@ietf.org; ipv6@ietf.org > > Subject: [dhcwg] RE: purpose of m/o bit > >=20 > > Ralph Droms wrote: > >=20 > > > Seems to me I'm hearing two requirements out of this thread: > > >=20 > > > 1) Ability to indicate to a host "DHCP is not available on=20 > > this link", > > > with the expectation that the host won't send any DHCP messages > > >=20 > > > 2) Ability for a host to get all desired and available DHCP > > > configuration with a single DHCP message exchange > > > - if a host wants HCB, it sends an HCB request (Solicit) > > > and receives > > > HCB and/or ICB replies > > > - if a host wants ICB, it sends an ICB request > > > (Information-request) > > > and receives ICB replies > > >=20 > > > 1 is a requirement in scenarios with limited resources (e.g., > > > wireless), where polling for DHCP is unacceptable. 2 is a > > > requirement to avoid timeout delays or other complexity in getting > > > ICB reply when=20 > > > host would > > > prefer HCB reply. > > >=20 > > > If I've got that right, we can meet the two requirements=20 > > with a couple > > > of small updates to existing specs: > > >=20 > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > > service is available over the link through which the RA > > > was received > > > (no differentiation between HCB and ICB DHCP) > > >=20 > > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > > supply an ICB, the server can respond with the ICB reply=20 > > (note that > > > according RFC 3115, the server would respond with an "HCB-nak" > > > [Advertise containing only an error code]) > > >=20 > > > In addition to meeting the requirements, these updates are=20 > > mostly (if > > > not entirely) operationally compatible with existing clients and > > > servers.=20 > >=20 > > I completely agree with this analysis and support proceeding on this > > basis. But it does beg the question, why do we need two bits=20 > > to signal a > > binary condition? > >=20 > > -- Mat > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:32:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhl6-0006ai-6y; Fri, 27 May 2005 12:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhl5-0006aa-52; Fri, 27 May 2005 12:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24974; Fri, 27 May 2005 12:32:24 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi3u-0007Kk-Ba; Fri, 27 May 2005 12:51:55 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id EC6341A5; Fri, 27 May 2005 12:29:55 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:32:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:32:12 -0400 Message-ID: <936A4045C332714F975800409DE092405414F8@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViu/KLWFDdMW0aQBKaNLO1HM9CWgAHYKxA From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 27 May 2005 16:32:14.0076 (UTC) FILETIME=[A38513C0:01C562D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org m =3D=3D use dhc for addresses, o =3D=3D use dhc for just configuration = bow do you do this with one bit? neither m or o not set says don't use dhc. thus my reason for ternary. thx /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Friday, May 27, 2005 8:59 AM > To: matthew.ford@bt.com > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: [dhcwg] RE: purpose of m/o bit >=20 > Mat - thanks for your review and input. I specified the two bits only > for backward compatibility with existing implementations. >=20 > I imagine we could design a specification that retains one bit and > deprecates the other, with rules about the appearance of the depre > backward compatibility. At least, this spec would need a note > explaining why there are two bits in the spec and=20 > recommending that new > implementations use, for example, just the M bit. >=20 > - Ralph >=20 > On Fri, 2005-05-27 at 13:41 +0100, matthew.ford@bt.com wrote: > > Ralph Droms wrote: > >=20 > > > Seems to me I'm hearing two requirements out of this thread: > > >=20 > > > 1) Ability to indicate to a host "DHCP is not available=20 > on this link", > > > with the expectation that the host won't send any DHCP messages > > >=20 > > > 2) Ability for a host to get all desired and available DHCP > > > configuration with a single DHCP message exchange > > > - if a host wants HCB, it sends an HCB request (Solicit) > > > and receives > > > HCB and/or ICB replies > > > - if a host wants ICB, it sends an ICB request > > > (Information-request) > > > and receives ICB replies > > >=20 > > > 1 is a requirement in scenarios with limited resources (e.g., > > > wireless), where polling for DHCP is unacceptable. 2 is a > > > requirement to avoid timeout delays or other complexity in getting > > > ICB reply when=20 > > > host would > > > prefer HCB reply. > > >=20 > > > If I've got that right, we can meet the two requirements=20 > with a couple > > > of small updates to existing specs: > > >=20 > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > > service is available over the link through which the RA > > > was received > > > (no differentiation between HCB and ICB DHCP) > > >=20 > > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > > supply an ICB, the server can respond with the ICB=20 > reply (note that > > > according RFC 3115, the server would respond with an "HCB-nak" > > > [Advertise containing only an error code]) > > >=20 > > > In addition to meeting the requirements, these updates=20 > are mostly (if > > > not entirely) operationally compatible with existing clients and > > > servers.=20 > >=20 > > I completely agree with this analysis and support proceeding on this > > basis. But it does beg the question, why do we need two=20 > bits to signal a > > binary condition? > >=20 > > -- Mat >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:34:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhn6-0006iS-JG; Fri, 27 May 2005 12:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhn5-0006iK-KE; Fri, 27 May 2005 12:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25126; Fri, 27 May 2005 12:34:29 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi5t-0007ON-TM; Fri, 27 May 2005 12:53:59 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id B58C615B; Fri, 27 May 2005 12:31:59 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:34:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:34:13 -0400 Message-ID: <936A4045C332714F975800409DE092405414FC@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVivR4fj/53Kf3FRE61JK+gHvwwhgAAGKFAAAcQD2A= From: "Bound, Jim" To: "Bernie Volz (volz)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 16:34:15.0462 (UTC) FILETIME=[EBDF1C60:01C562D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org because thinking was router should be able to tell client use for addresses and not configuration or use just for configuration, or don't even use dhc. no comment on that I agree or disagree this is just what the purpose was. agree or not agree can only happen once people get why what is there is there. /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bernie Volz (volz) > Sent: Friday, May 27, 2005 9:18 AM > To: Iljitsch van Beijnum > Cc: ipv6@ietf.org; dhcwg@ietf.org; Ralph Droms (rdroms) > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > Why? >=20 > If we update the DHCPv6 protocol to allow "other=20 > configuration" options > to be returned in an Advertise for a Solicit,=20 > Information-Request/Reply > and Solicit/Advertise are then essentially the same in a stateless > DHCPv6 environment (though the Solicit does require a client=20 > identifier > and likely may require a IA_* option). >=20 > Note that this will require changes to 3315 and 3736 - since stateless > servers will need to respond to Solicits with Advertises. >=20 > Clients that can do full 3315, would. And, if no stateful=20 > DHCPv6 server > is available but a stateless is, it will get "other configuration > parameters". >=20 > Clients that only do 3736 would do that and get "other configuration > parameters". >=20 > I think if we have two bits, we'll just be back to some of the edge > conditions (what if M is set, but O isn't, etc). >=20 > These changes would potentially cause some issues with any deployments > today because the clients and servers do not support this "new" > behavior, but it that's why it is critical we work this out ASAP. > However, those clients, if they use the M & O bits, could=20 > continue to do > what they do today -- since both bits are available. It is just new > clients with old servers that may have issues. >=20 > - Bernie >=20 > > -----Original Message----- > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > > Sent: Friday, May 27, 2005 9:07 AM > > To: Bernie Volz (volz) > > Cc: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > > dhcwg@ietf.org; ipv6@ietf.org > > Subject: Re: [dhcwg] RE: purpose of m/o bit > >=20 > > On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote: > >=20 > > > I think if we come to agreement on having no distinction=20 > between the > > > bits, we should deprecate one of the bits (O-bit?); though for =20 > > > backwards > > > compatibility, we can't remove/reassign it until many years from =20 > > > now (if > > > ever). > >=20 > > I think having M =3D 0, O =3D 1 would be useful as an indication = that =20 > > clients should use the simplified stateless DHCPv6 rather than the =20 > > full DHCPv6. > >=20 > > And I would object to any deprecation on the basis that=20 > there isn't =20 > > enough operational experience to be able to make a good decision. > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:36:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhp9-0006rV-63; Fri, 27 May 2005 12:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhp8-0006rI-1a; Fri, 27 May 2005 12:36:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25276; Fri, 27 May 2005 12:36:35 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi7x-0007Ri-EC; Fri, 27 May 2005 12:56:06 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 13E85181; Fri, 27 May 2005 12:34:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:35:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:35:33 -0400 Message-ID: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViz18hoHkosVPZSMmenVDiSlovbAACqaaA From: "Bound, Jim" To: "Ted Lemon" , "Bernie Volz (volz)" X-OriginalArrivalTime: 27 May 2005 16:35:35.0256 (UTC) FILETIME=[1B6EB580:01C562DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org ughh. sorry know of three production servers in use Lucent, HP, and Linux version. /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 11:16 AM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; ipv6@ietf.org;=20 > Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote: > > These changes would potentially cause some issues with any=20 > deployments > > today because the clients and servers do not support this "new" > > behavior, but it that's why it is critical we work this out ASAP. > > However, those clients, if they use the M & O bits, could continue =20 > > to do > > what they do today -- since both bits are available. It is just new > > clients with old servers that may have issues. >=20 > I may not have a full sense of the market, but FWIW I don't get the =20 > impression that backwards compatibility for servers is a huge issue =20 > at the moment. So a simplifying change at this point would be a =20 > good thing. There have certainly been times in the past when we've =20 > regretted our failure to make simplifying changes in the DHCP =20 > protocol back when it wasn't widely deployed. (Or at least=20 > I have - =20 > I can't really speak for other members of the wg.) >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:40:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhsg-0007bF-O4; Fri, 27 May 2005 12:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhsf-0007b0-Ca; Fri, 27 May 2005 12:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25883; Fri, 27 May 2005 12:40:14 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiBS-0007Zm-RH; Fri, 27 May 2005 12:59:45 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 3F8A556883; Fri, 27 May 2005 09:39:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 09:39:52 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > ughh. sorry know of three production servers in use Lucent, HP, and > Linux version. > That's not what I mean. The point is that it's early days, and updating servers isn't a hard problem. My point is that I don't know of any widespread deployments we'd be breaking right now, not that there are no implementations. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:42:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhvD-0008H2-SX; Fri, 27 May 2005 12:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhvB-0008Ge-Kr; Fri, 27 May 2005 12:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26299; Fri, 27 May 2005 12:42:51 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiE1-0007hS-8z; Fri, 27 May 2005 13:02:21 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 8E81A16C; Fri, 27 May 2005 12:42:44 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:41:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:41:55 -0400 Message-ID: <936A4045C332714F975800409DE09240541502@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViu/KLWFDdMW0aQBKaNLO1HM9CWgAHYKxAAABPUvA= From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 27 May 2005 16:41:57.0288 (UTC) FILETIME=[FF242A80:01C562DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org hmmm I wonder if part of the confusion is for prefix delegation to happen maybe that should be signaled by the m bit. The o bit or its function should be pristine to mean only use dhc for configuration data like dns, link information, services information etc. when m bit set it is client/server implementation defined by admins for dhc whether stateless dhc is used or full dhc? /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bound, Jim > Sent: Friday, May 27, 2005 12:32 PM > To: Ralph Droms; matthew.ford@bt.com > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > m =3D=3D use dhc for addresses, o =3D=3D use dhc for just = configuration bow do > you do this with one bit? neither m or o not set says don't use dhc. > thus my reason for ternary. >=20 > thx > /jim=20 >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > > On Behalf Of Ralph Droms > > Sent: Friday, May 27, 2005 8:59 AM > > To: matthew.ford@bt.com > > Cc: dhcwg@ietf.org; ipv6@ietf.org > > Subject: [dhcwg] RE: purpose of m/o bit > >=20 > > Mat - thanks for your review and input. I specified the=20 > two bits only > > for backward compatibility with existing implementations. > >=20 > > I imagine we could design a specification that retains one bit and > > deprecates the other, with rules about the appearance of the depre > > backward compatibility. At least, this spec would need a note > > explaining why there are two bits in the spec and=20 > > recommending that new > > implementations use, for example, just the M bit. > >=20 > > - Ralph > >=20 > > On Fri, 2005-05-27 at 13:41 +0100, matthew.ford@bt.com wrote: > > > Ralph Droms wrote: > > >=20 > > > > Seems to me I'm hearing two requirements out of this thread: > > > >=20 > > > > 1) Ability to indicate to a host "DHCP is not available=20 > > on this link", > > > > with the expectation that the host won't send any=20 > DHCP messages > > > >=20 > > > > 2) Ability for a host to get all desired and available DHCP > > > > configuration with a single DHCP message exchange > > > > - if a host wants HCB, it sends an HCB request (Solicit) > > > > and receives > > > > HCB and/or ICB replies > > > > - if a host wants ICB, it sends an ICB request > > > > (Information-request) > > > > and receives ICB replies > > > >=20 > > > > 1 is a requirement in scenarios with limited resources (e.g., > > > > wireless), where polling for DHCP is unacceptable. 2 is a > > > > requirement to avoid timeout delays or other complexity=20 > in getting > > > > ICB reply when=20 > > > > host would > > > > prefer HCB reply. > > > >=20 > > > > If I've got that right, we can meet the two requirements=20 > > with a couple > > > > of small updates to existing specs: > > > >=20 > > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > > > service is available over the link through which the RA > > > > was received > > > > (no differentiation between HCB and ICB DHCP) > > > >=20 > > > > 2) If a DHCP server receives an HCB request (Solicit)=20 > but can only > > > > supply an ICB, the server can respond with the ICB=20 > > reply (note that > > > > according RFC 3115, the server would respond with an=20 > "HCB-nak" > > > > [Advertise containing only an error code]) > > > >=20 > > > > In addition to meeting the requirements, these updates=20 > > are mostly (if > > > > not entirely) operationally compatible with existing clients and > > > > servers.=20 > > >=20 > > > I completely agree with this analysis and support=20 > proceeding on this > > > basis. But it does beg the question, why do we need two=20 > > bits to signal a > > > binary condition? > > >=20 > > > -- Mat > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:45:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhxN-0000us-T8; Fri, 27 May 2005 12:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhxL-0000se-4T; Fri, 27 May 2005 12:45:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26761; Fri, 27 May 2005 12:45:04 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiGA-0007ow-Mq; Fri, 27 May 2005 13:04:34 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id D2A11169; Fri, 27 May 2005 12:44:57 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:44:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:44:02 -0400 Message-ID: <936A4045C332714F975800409DE09240541507@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi2r9DQ5A0CMcRRJ+iCYXM4pW08gAAE68A From: "Bound, Jim" To: "Ted Lemon" X-OriginalArrivalTime: 27 May 2005 16:44:04.0330 (UTC) FILETIME=[4ADD3CA0:01C562DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org sure but breaking production code has to jump a higher bar regardless and I am not convinced that all have come to good set of statements and assumptions what those bits mean right now and I think that is prudent before changing them. prefix delegation puts another and new variable in the analysis I think now. /jim=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: Bernie Volz (volz); dhcwg@ietf.org; Iljitsch van Beijnum;=20 > ipv6@ietf.org; Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 12:48:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbi0k-0003Bz-Ew; Fri, 27 May 2005 12:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbi0h-0003BL-4i; Fri, 27 May 2005 12:48:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27477; Fri, 27 May 2005 12:48:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiJV-000822-L3; Fri, 27 May 2005 13:08:03 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 May 2005 09:48:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RGlhmM016376; Fri, 27 May 2005 09:48:17 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:48:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 12:48:10 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi2tNXlKPR+n/8TluP1pvW3uJSzwAAFS7Q From: "Bernie Volz \(volz\)" To: "Ted Lemon" , "Bound, Jim" X-OriginalArrivalTime: 27 May 2005 16:48:11.0844 (UTC) FILETIME=[DE64E040:01C562DB] X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Also, the servers aren't impacted by the M/O bits. They don't use them. Though changing the DHCPv6 protocol as we've contemplated, would impact the servers and the clients. But if you're currently deploying with either the M set or the O set, there is no problem. Sure, if a client talks to a new server it might get other configuration parameters in an Advertise, but I doubt that would cause it to fail (it would likely just ignore the parameters). The only situation where these changes would impact clients is if a new client communicates with an old server. Since the old server won't send other configuration parameters. So, yes the servers would need to be upgraded in order to use newer clients. - Bernie=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: Bernie Volz (volz); dhcwg@ietf.org; Iljitsch van Beijnum;=20 > ipv6@ietf.org; Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 13:31:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbigF-0003RR-Ue; Fri, 27 May 2005 13:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbigD-0003RJ-O6; Fri, 27 May 2005 13:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01069; Fri, 27 May 2005 13:31:26 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbiz2-0000m9-9G; Fri, 27 May 2005 13:50:58 -0400 Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4RHUHGJ021508; Fri, 27 May 2005 10:30:17 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4RHUDxi548994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2005 10:30:14 -0700 (PDT) Message-ID: <42975938.8060700@sun.com> Date: Fri, 27 May 2005 10:30:32 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117148729.7913.26.camel@localhost.localdomain> In-Reply-To: <1117148729.7913.26.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph Droms wrote: > Seems to me I'm hearing two requirements out of this thread: > > 1) Ability to indicate to a host "DHCP is not available on this link", > with the expectation that the host won't send any DHCP messages > > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request (Information-request) > and receives ICB replies I the case where the network admin wants to do stateless address autoconfiguration and has DHCP available for ICB, how inefficient will the above be? Wouldn't this mean that the hosts which are implemented to handle HCB as well as ICB, would always try with a Solicit i.e. they would end up doing a 4 packet DHCP exchange. Had the host known that HCB was not available, a 2 packet exchange would have been sufficient. Thinking about hosts moving between different links, the difference between 4 and 2 packets for DHCP ICB might matter. Hence my question how useful it would be to have 3) Ability for the host to find out from the RA that it doesn't need to bother with HCB since only ICB is available on the network. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 13:41:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbipz-0005Ve-Ej; Fri, 27 May 2005 13:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbipu-0005UB-6p for dhcwg@megatron.ietf.org; Fri, 27 May 2005 13:41:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02461 for ; Fri, 27 May 2005 13:41:29 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbj8j-0001E3-BD for dhcwg@ietf.org; Fri, 27 May 2005 14:00:58 -0400 Received: by rproxy.gmail.com with SMTP id a41so412632rng for ; Fri, 27 May 2005 10:41:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BtEtjmO+OoalkF0k63/yxlmTqW2eDqOllzQjSeizcQC+L0RQPiW77UG8k3SyPxZltfX/J1fmOCNZUx5/aoyUWKyphZUErXENVSdlmd6HafPTjs3rIL71Mep9d+TCt6G16i41LeD8WjRC09xeu1WHodmpJk1xIuvP8cCtiATtqgQ= Received: by 10.38.5.73 with SMTP id 73mr3791897rne; Fri, 27 May 2005 10:41:25 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Fri, 27 May 2005 10:41:24 -0700 (PDT) Message-ID: <10e14db20505271041115527ee@mail.gmail.com> Date: Fri, 27 May 2005 23:11:24 +0530 From: Syam Madanapalli To: ipv6@ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] RE: purpose of m/o bit In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Iljitsch van Beijnum , "Bernie Volz \(volz\)" , Ted Lemon , "Bound, Jim" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Isn't it such a long idscussion a proof for the confusion in understanding the M/O bits? Instead of leaving the discussion here, thinking that there is no confusion or be fore taking any radical changes (either discarding M or O or both flags,= or=20 making changes to the DHCPv6 protocols), it is better to document the inted= ed=20 use of M/O flags as an informational document, so that we will have uniform= =20 implementations in th future. I am sure this (intended use of M/O flags) is very obvious for some people here, but definitely help many others. Also this information will be handy for the implementer. - Syam _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 13:42:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbiqj-0005qo-UL; Fri, 27 May 2005 13:42:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbiqi-0005qD-0b; Fri, 27 May 2005 13:42:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02647; Fri, 27 May 2005 13:42:19 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbj9U-0001Hy-Oq; Fri, 27 May 2005 14:01:48 -0400 Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4RHgDGJ001380; Fri, 27 May 2005 10:42:13 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4RHgCtw553061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2005 10:42:13 -0700 (PDT) Message-ID: <42975C06.8010200@sun.com> Date: Fri, 27 May 2005 10:42:30 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernie Volz (volz)" Subject: Re: [dhcwg] RE: purpose of m/o bit References: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie Volz (volz) wrote: > Why? > > If we update the DHCPv6 protocol to allow "other configuration" options > to be returned in an Advertise for a Solicit, Information-Request/Reply > and Solicit/Advertise are then essentially the same in a stateless > DHCPv6 environment (though the Solicit does require a client identifier > and likely may require a IA_* option). > > Note that this will require changes to 3315 and 3736 - since stateless > servers will need to respond to Solicits with Advertises. Do we know we can change DHCPv6 that way without causing compatibility problems for any existing DHCPv6 clients? I can see such a client not expecting configuration information in the advertise message. Or are we assuming that there are no 3315 DHCP clients out there? There might also be compatibility issues on the server, since this appears to assume that a 3736-only server will handle Solicit messages, unless the clients have some logic to fallback from using Solicit to using Information-Requests after a few attempts. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:11:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjIe-0001t7-5a; Fri, 27 May 2005 14:11:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjIa-0001sY-Mw; Fri, 27 May 2005 14:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08153; Fri, 27 May 2005 14:11:07 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjbQ-000347-0U; Fri, 27 May 2005 14:30:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:10:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RIARlU013850; Fri, 27 May 2005 14:10:55 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:09:56 -0400 Received: from 161.44.65.252 ([161.44.65.252]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 18:09:56 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 14:10:25 -0400 From: Ralph Droms To: Erik Nordmark In-Reply-To: <42975938.8060700@sun.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117148729.7913.26.camel@localhost.localdomain> <42975938.8060700@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 14:10:24 -0400 Message-Id: <1117217425.26540.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 18:09:56.0686 (UTC) FILETIME=[49E85EE0:01C562E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Erik - the idea is to allow a client to initiate either HCB or ICB with the same message, which turns into a 4 message exchange for HCB (2 messages w/ "rapid commit") or 2 message exchange for ICB. - Ralph On Fri, 2005-05-27 at 10:30 -0700, Erik Nordmark wrote: > Ralph Droms wrote: > > Seems to me I'm hearing two requirements out of this thread: > > > > 1) Ability to indicate to a host "DHCP is not available on this link", > > with the expectation that the host won't send any DHCP messages > > > > 2) Ability for a host to get all desired and available DHCP > > configuration with a single DHCP message exchange > > - if a host wants HCB, it sends an HCB request (Solicit) and receives > > HCB and/or ICB replies > > - if a host wants ICB, it sends an ICB request (Information-request) > > and receives ICB replies > > I the case where the network admin wants to do stateless address > autoconfiguration and has DHCP available for ICB, how inefficient will > the above be? > > Wouldn't this mean that the hosts which are implemented to handle HCB as > well as ICB, would always try with a Solicit i.e. they would end up > doing a 4 packet DHCP exchange. Had the host known that HCB was not > available, a 2 packet exchange would have been sufficient. > > Thinking about hosts moving between different links, the difference > between 4 and 2 packets for DHCP ICB might matter. > > Hence my question how useful it would be to have > 3) Ability for the host to find out from the RA that it doesn't need to > bother with HCB since only ICB is available on the network. > > Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:13:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjL0-0002A1-A6; Fri, 27 May 2005 14:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjKw-00029o-EK; Fri, 27 May 2005 14:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08593; Fri, 27 May 2005 14:13:33 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbjdl-000388-Sz; Fri, 27 May 2005 14:33:03 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 649A817F; Fri, 27 May 2005 14:13:17 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:12:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 14:12:22 -0400 Message-ID: <936A4045C332714F975800409DE09240541571@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi41F2StgiEOyIQqWMb30BI0w02gABC6DQ From: "Bound, Jim" To: "Syam Madanapalli" , , X-OriginalArrivalTime: 27 May 2005 18:12:24.0611 (UTC) FILETIME=[A213EF30:01C562E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Iljitsch van Beijnum , "Bernie Volz \(volz\)" , Ted Lemon , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org at least have discussion where all agree for sure. not clear a document is needed if we can put it in dhc or possibly biz update to 2462 yet again :----) /jim=20 > -----Original Message----- > From: Syam Madanapalli [mailto:smadanapalli@gmail.com]=20 > Sent: Friday, May 27, 2005 1:41 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Cc: Ted Lemon; Bound, Jim; Iljitsch van Beijnum; Ralph Droms=20 > (rdroms); Bernie Volz (volz); Thomas Narten;=20 > jinmei@isl.rdc.toshiba.co.jp > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > Isn't it such a long idscussion a proof for the confusion in > understanding the M/O > bits? Instead of leaving the discussion here, thinking that there is > no confusion or > be fore taking any radical changes (either discarding M or O=20 > or both flags, or=20 > making changes to the DHCPv6 protocols), it is better to=20 > document the inteded=20 > use of M/O flags as an informational document, so that we=20 > will have uniform=20 > implementations in th future. I am sure this (intended use of M/O > flags) is very > obvious for some people here, but definitely help many others. Also > this information > will be handy for the implementer. >=20 > - Syam >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjVP-0005Pq-92; Fri, 27 May 2005 14:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjVK-0005Pf-N7; Fri, 27 May 2005 14:24:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09737; Fri, 27 May 2005 14:24:17 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbjo9-0003T9-Um; Fri, 27 May 2005 14:43:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:24:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RINQ5U018277; Fri, 27 May 2005 14:24:04 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:24:03 -0400 Received: from 161.44.65.252 ([161.44.65.252]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 18:24:02 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 14:24:31 -0400 Subject: Re: [dhcwg] RE: purpose of m/o bit From: Ralph Droms To: Syam Madanapalli In-Reply-To: <10e14db20505271041115527ee@mail.gmail.com> References: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> <10e14db20505271041115527ee@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 14:24:31 -0400 Message-Id: <1117218271.26540.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 18:24:03.0134 (UTC) FILETIME=[426E15E0:01C562E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , dhcwg@ietf.org, "Bound, Jim" , Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org But the discussion says nothing about how complex the underlying issues are. I think there is significant room for simplification (but no more simplification than necessary!), especially if we set aside preconceptions about the M/O bits and look at what we've learned through discussion, implementation and deployment planning. - Ralph On Fri, 2005-05-27 at 23:11 +0530, Syam Madanapalli wrote: > Isn't it such a long idscussion a proof for the confusion in > understanding the M/O > bits? Instead of leaving the discussion here, thinking that there is > no confusion or > be fore taking any radical changes (either discarding M or O or both flags, or > making changes to the DHCPv6 protocols), it is better to document the inteded > use of M/O flags as an informational document, so that we will have uniform > implementations in th future. I am sure this (intended use of M/O > flags) is very > obvious for some people here, but definitely help many others. Also > this information > will be handy for the implementer. > > - Syam _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:25:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjWk-0005c0-7X; Fri, 27 May 2005 14:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjWj-0005bs-0e; Fri, 27 May 2005 14:25:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09813; Fri, 27 May 2005 14:25:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjpY-0003Us-3s; Fri, 27 May 2005 14:45:13 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:25:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RIPD5E018809; Fri, 27 May 2005 14:25:31 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:25:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 14:25:18 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi44Fak3O3YdWHTx6k5y/j/63PvwABJ7ww From: "Bernie Volz \(volz\)" To: "Erik Nordmark" X-OriginalArrivalTime: 27 May 2005 18:25:18.0990 (UTC) FILETIME=[6FA4CAE0:01C562E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Erik: As I believe Spock said - "there are always possibilities". But realisticly, do you expect any old client to check for these "other configuration" parameters and if they got them, what might they do? Drop the packet? Well, that is what the client would essentially have done anyway since it got no addresses. So, while a poorly implemented client might well crash, I can't really see that being likely and it would be worth it to get that client fixed as quickly as possible since it doesn't adhere to the "be liberal in what you receive" IETF "rule". If people are really concerned about this, we can always add a DHCPv6 option to the Solicit that tells the server "I'm a new client and am able to receive other configuration parameters even if you're not going to give me any addresses." Thus, the old servers would ignore this option and new servers would know that it is OK to do this. Regarding the other issue, why would a stateless only client ever say "Oh, I'll send Solicit instead of Information-Request"? If they did that today, they wouldn't get very far. Sure, if a new client sent Solicits and the old stateless server ignored them, there would be a problem (as I pointed out in previous message(s)). But, I suspect that the magnitude of that problem is small. And, the sooner we resolve these issues and update the specs, the fewer implementations will have issues (I know of a bunch of implementations under development so if we wait much longer ...). An old client that sends Solicits to a stateless server won't get very far today anyway, so we can ignore that case. And, if it fails over to use Information-Request, great. - Bernie > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com]=20 > Sent: Friday, May 27, 2005 1:43 PM > To: Bernie Volz (volz) > Cc: Iljitsch van Beijnum; ipv6@ietf.org; dhcwg@ietf.org;=20 > Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > Bernie Volz (volz) wrote: > > Why? > >=20 > > If we update the DHCPv6 protocol to allow "other=20 > configuration" options > > to be returned in an Advertise for a Solicit,=20 > Information-Request/Reply > > and Solicit/Advertise are then essentially the same in a stateless > > DHCPv6 environment (though the Solicit does require a=20 > client identifier > > and likely may require a IA_* option). > >=20 > > Note that this will require changes to 3315 and 3736 -=20 > since stateless > > servers will need to respond to Solicits with Advertises. >=20 > Do we know we can change DHCPv6 that way without causing=20 > compatibility=20 > problems for any existing DHCPv6 clients? I can see such a client not=20 > expecting configuration information in the advertise message. > Or are we assuming that there are no 3315 DHCP clients out there? >=20 > There might also be compatibility issues on the server, since this=20 > appears to assume that a 3736-only server will handle Solicit=20 > messages,=20 > unless the clients have some logic to fallback from using Solicit to=20 > using Information-Requests after a few attempts. >=20 > Erik >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:39:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjkR-0000ht-3x; Fri, 27 May 2005 14:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjkO-0000hl-VJ; Fri, 27 May 2005 14:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11539; Fri, 27 May 2005 14:39:51 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbk3E-0003xO-NB; Fri, 27 May 2005 14:59:22 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7F39656898; Fri, 27 May 2005 11:39:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C095C5C-F1A7-45C0-B227-1E3D5DEC35FA@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 11:39:40 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , Erik Nordmark , ipv6@ietf.org, Iljitsch van Beijnum X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote: > If people are really concerned about this, we can always add a DHCPv6 > option to the Solicit that tells the server "I'm a new client and am > able to receive other configuration parameters even if you're not > going > to give me any addresses." Thus, the old servers would ignore this > option and new servers would know that it is OK to do this. DHCPv6 is not a full standard. I don't think it's widely deployed at this point. I would rather take the risk, as you suggest, than add an extra protocol to negotiate whether we can do this - it's extra logic in the server that will be needed for zero clients two years from now - just another piece of unused code that could be buggy, because it's never used, and thus could be an avenue of attack for some enterprising young script kiddie. The time to get conservative about breaking clients by sending them unexpected responses will come, but it hasn't come yet, IMHO. I haven't heard anything to contradict this - has anyone else? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:41:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjmO-0000zQ-6f; Fri, 27 May 2005 14:41:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjmM-0000zI-FN; Fri, 27 May 2005 14:41:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11630; Fri, 27 May 2005 14:41:53 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbk5B-0003zR-TM; Fri, 27 May 2005 15:01:23 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 21E0415B; Fri, 27 May 2005 14:39:20 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:40:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 14:40:50 -0400 Message-ID: <936A4045C332714F975800409DE0924054158F@tayexc14.americas.cpqcorp.net> Thread-Topic: Where do we do this work: purpose of m/o bit Thread-Index: AcVi44Fak3O3YdWHTx6k5y/j/63PvwABJ7wwAADDAvA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 18:40:52.0749 (UTC) FILETIME=[9C351BD0:01C562EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] Where do we do this work: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Do we need to continue cross posting and we should decide where we sort this out IPv6 or DHC. =20 My suggestion is the bits need to be understood for ND and Addrconf thus lets get this done in the IPv6 WG. That would make job of what DHC has to do easy. /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjuc-000373-Vy; Fri, 27 May 2005 14:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjub-00036e-C6; Fri, 27 May 2005 14:50:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13237; Fri, 27 May 2005 14:50:24 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkDR-0004Qh-Q1; Fri, 27 May 2005 15:09:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1642218B; Fri, 27 May 2005 14:47:54 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:49:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 14:49:52 -0400 Message-ID: <936A4045C332714F975800409DE09240541593@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi67csnJmM6yf0QHSzndYwluxIEwAAPqJQ From: "Bound, Jim" To: "Ted Lemon" , "Bernie Volz (volz)" X-OriginalArrivalTime: 27 May 2005 18:49:53.0556 (UTC) FILETIME=[DE8DB540:01C562EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Iljitsch van Beijnum , dhcwg@ietf.org, Erik Nordmark , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org my input is dhcpv6 implementation and deployment state is quite flexible for this topic and code affect and config/admin affect. If we move to unicast instead of multicast for dhc answer would be different ok. /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 2:40 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); Erik Nordmark;=20 > ipv6@ietf.org; Iljitsch van Beijnum > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote: > > If people are really concerned about this, we can always=20 > add a DHCPv6 > > option to the Solicit that tells the server "I'm a new client and am > > able to receive other configuration parameters even if you're not =20 > > going > > to give me any addresses." Thus, the old servers would ignore this > > option and new servers would know that it is OK to do this. >=20 > DHCPv6 is not a full standard. I don't think it's widely deployed =20 > at this point. I would rather take the risk, as you suggest, than =20 > add an extra protocol to negotiate whether we can do this - it's =20 > extra logic in the server that will be needed for zero clients two =20 > years from now - just another piece of unused code that could be =20 > buggy, because it's never used, and thus could be an avenue=20 > of attack =20 > for some enterprising young script kiddie. >=20 > The time to get conservative about breaking clients by sending them =20 > unexpected responses will come, but it hasn't come yet, IMHO. I =20 > haven't heard anything to contradict this - has anyone else? >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjv4-0003GS-Sh; Fri, 27 May 2005 14:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjv0-0003Ff-EX; Fri, 27 May 2005 14:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13363; Fri, 27 May 2005 14:50:49 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkDp-0004TE-RU; Fri, 27 May 2005 15:10:19 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:50:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RInw5Q026459; Fri, 27 May 2005 14:50:34 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:50:31 -0400 Received: from 161.44.65.252 ([161.44.65.252]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 May 2005 18:50:31 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 14:51:00 -0400 From: Ralph Droms To: "Bound, Jim" In-Reply-To: <936A4045C332714F975800409DE0924054158F@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924054158F@tayexc14.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 14:51:00 -0400 Message-Id: <1117219860.26540.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 18:50:31.0741 (UTC) FILETIME=[F55046D0:01C562EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: Where do we do this work: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Jim - it would be great to sort this out in one group or the other. But I think the eventual solution will require input from both ipv6 and dhc WGs, so we might have to continue the cross-posting or set up a short- lived mailing list just for this discussion. - Ralph On Fri, 2005-05-27 at 14:40 -0400, Bound, Jim wrote: > Do we need to continue cross posting and we should decide where we sort > this out IPv6 or DHC. > > My suggestion is the bits need to be understood for ND and Addrconf thus > lets get this done in the IPv6 WG. That would make job of what DHC has > to do easy. > > /jim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 14:56:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk04-0007fv-BI; Fri, 27 May 2005 14:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk02-0007fn-Ef; Fri, 27 May 2005 14:56:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14872; Fri, 27 May 2005 14:56:01 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkIs-0004yH-UO; Fri, 27 May 2005 15:15:31 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id A8DE013C; Fri, 27 May 2005 14:53:31 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:55:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 14:55:14 -0400 Message-ID: <936A4045C332714F975800409DE09240541596@tayexc14.americas.cpqcorp.net> Thread-Topic: Where do we do this work: purpose of m/o bit Thread-Index: AcVi7PutDOmKB+EIRDSKU0jVK2QiLgAADnSw From: "Bound, Jim" To: "Ralph Droms" X-OriginalArrivalTime: 27 May 2005 18:55:15.0575 (UTC) FILETIME=[9E7DE870:01C562ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] RE: Where do we do this work: purpose of m/o bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph, I think there are two parts. This has affect to neighbor discovery protocol too. That is clearly the IPv6 WG. It also then affect to Addrconf and that is IPv6 WG. I just sent mail to IPv6 taking this as baby step to first ask a very basic assumption question. I want to see how that simple mail plays out. This has been going on too long and part of the problem is pure communications vectors not being done logically simply for discussion. If others want the cross posting that is fine I just asked the question and would like to hear what people think that is all. thanks /jim=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Friday, May 27, 2005 2:51 PM > To: Bound, Jim > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: Where do we do this work: purpose of m/o bit >=20 > Jim - it would be great to sort this out in one group or the=20 > other. But > I think the eventual solution will require input from both=20 > ipv6 and dhc > WGs, so we might have to continue the cross-posting or set up a short- > lived mailing list just for this discussion. >=20 > - Ralph >=20 > On Fri, 2005-05-27 at 14:40 -0400, Bound, Jim wrote: > > Do we need to continue cross posting and we should decide=20 > where we sort > > this out IPv6 or DHC. =20 > >=20 > > My suggestion is the bits need to be understood for ND and=20 > Addrconf thus > > lets get this done in the IPv6 WG. That would make job of=20 > what DHC has > > to do easy. > >=20 > > /jim > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 15:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk4p-00017M-RE; Fri, 27 May 2005 15:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk4n-00016l-Gl; Fri, 27 May 2005 15:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15416; Fri, 27 May 2005 15:00:56 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkNb-0005Au-DU; Fri, 27 May 2005 15:20:26 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1421D56883; Fri, 27 May 2005 12:00:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <936A4045C332714F975800409DE09240541596@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE09240541596@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: Where do we do this work: purpose of m/o bit Date: Fri, 27 May 2005 12:00:43 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org, Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 27, 2005, at 11:55 AM, Bound, Jim wrote: > If others want the cross posting that is fine I just asked the > question > and would like to hear what people think that is all. Seems like part of what's going on is that we needed to have this discussion cross-posted a year or three ago, so it's probably better to keep cross-posting now and let the people who don't want to hear about it put up a filter to delete messages on the thread. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 15:09:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkDS-0002sx-6D; Fri, 27 May 2005 15:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkDQ-0002sm-3v; Fri, 27 May 2005 15:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16792; Fri, 27 May 2005 15:09:50 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkWF-0005Nx-VM; Fri, 27 May 2005 15:29:21 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id DFD06191; Fri, 27 May 2005 15:07:18 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:09:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 15:09:05 -0400 Message-ID: <936A4045C332714F975800409DE092405415AB@tayexc14.americas.cpqcorp.net> Thread-Topic: Implementation change affect from m and o bits Thread-Index: AcVi7401rK7TWYgKR/CwWrOGn5kLkA== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:09:06.0856 (UTC) FILETIME=[8DF95280:01C562EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] Implementation change affect from m and o bits X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The question asked is what is the implementation affect. I know something about this hands on from coding it :--) If it was just dhc client and dhc server that I will input can be changed rather easily to support a change in syntax and semantics, and as dhc for ipv6 is now just being deployed it will not be that painful to rev if that is what the dhc and ipv6 wgs want to do. That is my input on that end. Now if we started whacking basic architecture of dhc for IPv6 then I would give you a different answer. =20 But the m and o bit also affect the code path that scans the ND packet and looks for the m and o bit as other bits in ND. Then there is code from addrconf to help resolve the if condtions of what to do or not do from the m and o bit. This code base can be integrated and varys from implementer to implementer from discussions with many of you over the years when we talk about implementing our beloved IETF specifications. This part of the m and o bit code is long before the dhc client begins processing and the code to do dhc client procesing for ipv6. If we get rid of the m and o bit it will affect three pieces of code: ND, Addrconf Selection, and then dhc. So it is not just changing dhc code. So if we change the bits or alter them this is what we are facing. I think before we know whether this is worth the change or doing it we need to be sure what we want to do and then and only then can determine implementation decision. The other option is keep the bits as is and then change how they are used or verify how they are used and that will only affect the indirection for Addrconf and dhc most likely. /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 15:14:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkHd-0003xe-Ev; Fri, 27 May 2005 15:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkHb-0003xR-DW; Fri, 27 May 2005 15:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17432; Fri, 27 May 2005 15:14:09 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkaS-0005V7-77; Fri, 27 May 2005 15:33:40 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0F83E1A2; Fri, 27 May 2005 15:11:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:13:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 15:13:38 -0400 Message-ID: <936A4045C332714F975800409DE092405415B3@tayexc14.americas.cpqcorp.net> Thread-Topic: ND+Addrconf Parameters to state use of dhc on a link Thread-Index: AcVi44Fak3O3YdWHTx6k5y/j/63PvwABJ7wwAADDAvAAASHEIA== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:13:40.0017 (UTC) FILETIME=[30CA6210:01C562F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] ND+Addrconf Parameters to state use of dhc on a link X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I think Ted makes good point. I am now sending this to both lists. I will build my filter in a minute :--). So all respond to this mail with dissention if you have any. Resent text: Lets do one step at a time so assumptions are known first. Do we want bits within ND packet to inform nodes on a link to use or not use dhc?=20 This not to dicuss the placement, use of, or semantics of the bits. I think consensus is from the beginning that we do believe as a WG this is required? Any dissentiion that ND packet should not inform nodes of this on a link? If so why? thanks /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 15:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkRo-0006wk-Bj; Fri, 27 May 2005 15:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkRn-0006wc-GP; Fri, 27 May 2005 15:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18661; Fri, 27 May 2005 15:24:41 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbkkc-0005nY-Bz; Fri, 27 May 2005 15:44:10 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 67F661A4; Fri, 27 May 2005 15:22:09 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:24:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 15:24:20 -0400 Message-ID: <936A4045C332714F975800409DE092405415BB@tayexc14.americas.cpqcorp.net> Thread-Topic: Semantics of Stateful Bits for the Client Thread-Index: AcVi8a6ejz+kcwHqQ6yX9jDBY2V31w== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:24:22.0133 (UTC) FILETIME=[AF858250:01C562F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] Semantics of Stateful Bits for the Client X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org If we believe we will inform clients to use or not use dhc and I am going to guess all agree with that so we have to multitask here in cyberspace. What semantic conditions do we inform clients about when we inform them to use dhc via ND packet. Points from the many mails are as follows. 1. use dhc only to obtain addresses 2. use dhc only to obtain configuration parameters 3. use dhc to do 1 and 2. Does prefix delegation requires its own condidtion?=20 Is prefix delegation covered by 1 and then is it dhc process to decide what is done? /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 15:27:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkUs-0007I3-9H; Fri, 27 May 2005 15:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkUr-0007HX-4d; Fri, 27 May 2005 15:27:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18889; Fri, 27 May 2005 15:27:51 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbkng-0005qV-Ow; Fri, 27 May 2005 15:47:22 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 98E3E1A0; Fri, 27 May 2005 15:25:20 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:27:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 15:27:37 -0400 Message-ID: <936A4045C332714F975800409DE092405415C2@tayexc14.americas.cpqcorp.net> Thread-Topic: Addconf bit not set at all in ND Thread-Index: AcVi8iRA6pF57hNoSlOJZ5QRU3URLg== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:27:39.0485 (UTC) FILETIME=[252708D0:01C562F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: Subject: [dhcwg] Addconf bit not set at all in ND X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org There also came up the case that addrconf is not set at all. The client receives no advice from router or ND as to what they should do. 1. We leave this to industry to determine based on deployment and implementations. This is our default today. 2. We state default is start dhc client. I vote for #1 per Tim Hartrick email. Others? /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 16:28:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblRx-0007KO-Tq; Fri, 27 May 2005 16:28:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblRu-0007Jo-Su; Fri, 27 May 2005 16:28:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01088; Fri, 27 May 2005 16:28:53 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dblkm-0001eP-Fc; Fri, 27 May 2005 16:48:24 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RKRpmJ016777 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 22:27:51 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D2D@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338D2D@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C118F33-76F6-488D-96D4-D3EFA8AA4C71@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Fri, 27 May 2005 22:27:39 +0200 To: Bernie Volz ((volz)) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 27-mei-2005, at 18:16, Bernie Volz ((volz)) wrote: >> 1 1 send Solicit send Information-Request > But what happens if the stateful server is down and stateless is > running? Buy more servers?? Some solutions are simple. :-) > Though I would never recommend that a link have both of these > types of servers. I would assume that both types of servers wouldn't existing alongside. AFAIK, there is no reason that a server that does full DHCPv6 couldn't/shouldn't do answer stateless DHCPv6 queries as well. Only when there is no need for stateful DHCPv6, it would make sense to run a light-weight stateless server. For instance, on a residential type router. > We could easily resolve this by adjusting the DHCPv6 protocol as > proposed (ie, stateful and stateless servers can respond to Solicit > with > Advertise with just other configuration parameters). Wouldn't that put RFC 3376 out of business? > We really want to communicate three states in terms of the DHCPv6 > service available on the link: No DHCPv6, Stateful DHCPv6, and > Stateless > DHCPv6 -- not 4. Ok, I agree with you that those three are needed. I also think the fourth one is slightly useful, but that one isn't very imporant. Do we all agree that no DHCPv6/stateful DHCPv6/stateless DHCPv6 are all useful? > Note that this says nothing about what a client > supports (if the client can only do stateless, that's all it can do!). Right. > Clients would run DHCPv6 unless the "No DHCPv6" is set. :-) > So, perhaps we should deprecate M=1 *AND* O=1. Clients should > always run > DHCPv6 if EITHER M = 1 OR O = 1. If M=1, run stateful (if supported, > stateless otherwise). If O=1, run stateless (if supported). It already says in RFC 246x that O = 1 is implied when M = 1. I.e., the useful combinations are: M = 0, O = 0 M = 0, O = 1 M = 1, O = x > In any case, I would still fix the DHCPv6 protocol to allow Advertises > to return other configuration parameters when no addresses are > available > AND to require stateless DHCPv6 servers to support Solicit (with > Advertise with just other configuration parameters). I'm offering no opinions on that one. > I still believe deprecating the 2nd bit (O) is better. Disagree for various reasons. The way I see it, people may be interested in implementing clients and servers that just do stateless DHCPv6 (RFC 3376). Sure, it's probably doable to make any combination of stateful/stateless server and stateful/stateless client do something reasonable, but I'm convinced that knowing in advance (by virtue of the M = 0, O = 1 combination) on both the server and the client that we'll be stateless makes for much simpler implemenations. It also makes troubleshooting easier: with the O bit present, the M bit is a reliable indicator whether or not hosts will take addresses from a DCHPv6 server. Without the O bit the M bit is overloaded and the only way to determine whether the DHCPv6 server also supplies addresses (and possibly messes this job up) is by looking at a DHCPv6 interaction. Predictability is a highly regarded commodity in operational environments. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 16:41:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dble5-0001fK-V0; Fri, 27 May 2005 16:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbldz-0001eX-Gp; Fri, 27 May 2005 16:41:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02128; Fri, 27 May 2005 16:41:21 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dblwp-0001wi-C1; Fri, 27 May 2005 17:00:53 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 16:41:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RKf1lE027200; Fri, 27 May 2005 16:41:10 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 16:40:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Semantics of Stateful Bits for the Client Date: Fri, 27 May 2005 16:40:57 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338DCF@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Semantics of Stateful Bits for the Client Thread-Index: AcVi8a6ejz+kcwHqQ6yX9jDBY2V31wAClV/g From: "Bernie Volz \(volz\)" To: "Bound, Jim" , , X-OriginalArrivalTime: 27 May 2005 20:40:57.0793 (UTC) FILETIME=[62BF9310:01C562FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Does anyone really see any value in 1? And this is always possible - just don't configure the DHCPv6 server with any configuration parameters to send out. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bound, Jim > Sent: Friday, May 27, 2005 3:24 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Subject: [dhcwg] Semantics of Stateful Bits for the Client >=20 > If we believe we will inform clients to use or not use dhc and I am > going to guess all agree with that so we have to multitask here in > cyberspace. >=20 > What semantic conditions do we inform clients about when we=20 > inform them > to use dhc via ND packet. >=20 > Points from the many mails are as follows. >=20 > 1. use dhc only to obtain addresses >=20 > 2. use dhc only to obtain configuration parameters >=20 > 3. use dhc to do 1 and 2. >=20 > Does prefix delegation requires its own condidtion?=20 >=20 > Is prefix delegation covered by 1 and then is it dhc process to decide > what is done? >=20 > /jim >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 16:45:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblhW-0002I7-4J; Fri, 27 May 2005 16:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblhQ-0002G8-Of; Fri, 27 May 2005 16:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02431; Fri, 27 May 2005 16:44:54 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbm0C-00022G-96; Fri, 27 May 2005 17:04:26 -0400 Received: from jurassic.eng.sun.com ([129.146.68.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4RKimjO014010; Fri, 27 May 2005 14:44:48 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4RKil6R640553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2005 13:44:47 -0700 (PDT) Message-ID: <429786D1.3050407@sun.com> Date: Fri, 27 May 2005 13:45:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernie Volz (volz)" Subject: Re: [dhcwg] RE: purpose of m/o bit References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Bernie Volz (volz) wrote: > But realisticly, do you expect any old client to check for these "other > configuration" parameters and if they got them, what might they do? Drop > the packet? Well, that is what the client would essentially have done > anyway since it got no addresses. So, while a poorly implemented client > might well crash, I can't really see that being likely and it would be > worth it to get that client fixed as quickly as possible since it > doesn't adhere to the "be liberal in what you receive" IETF "rule". If we ignore DHCP client implementations which crash when they receive an unexpected option, what is the worst case of a RFC 3315 client in this case? Is it just to ignore the options in the Advertise message and proceed to send a Request message? That wouldn't be a big deal to me. > Regarding the other issue, why would a stateless only client ever say > "Oh, I'll send Solicit instead of Information-Request"? If they did that > today, they wouldn't get very far. The server compatibility issue isn't about today. The issue I see if we recommend that clients (which implement both RFC 3315 and 3736) always send a Solicit (when some bit is set in the RA telling it to use DHCP), then such a client will not interoperate with currently deployed 3736 DHCP servers. My understanding is that there is some deployment of 3736 DHCP servers (to do prefix delegation and DNS configuration, etc). Do we know that there is zero deployment of 3736 servers today? If we need to handle those, it seems like either - the client needs to try a few Solicits first, and if that fails, try an Information-Request. (Or try them in parallel??) - Have some indication in the RA that only 3736 service is available on the network, so that the client can do the Information-Request only. The second alternative seems simpler to me. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 16:59:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dblvs-0005Vg-Pl; Fri, 27 May 2005 16:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dblvq-0005VY-KB; Fri, 27 May 2005 16:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03661; Fri, 27 May 2005 16:59:48 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbmEh-0002Pj-KE; Fri, 27 May 2005 17:19:20 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 567635687E; Fri, 27 May 2005 13:59:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338DCF@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338DCF@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Semantics of Stateful Bits for the Client Date: Fri, 27 May 2005 13:59:36 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org, "Bound, Jim" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On May 27, 2005, at 1:40 PM, Bernie Volz (volz) wrote: > Does anyone really see any value in 1? > > And this is always possible - just don't configure the DHCPv6 server > with any configuration parameters to send out. 1 seems a bit odd, yes. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 20:28:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbpBh-0001Kc-B8; Fri, 27 May 2005 20:28:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbpBf-0001KU-TZ; Fri, 27 May 2005 20:28:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17335; Fri, 27 May 2005 20:28:22 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbpUY-0006TX-Gi; Fri, 27 May 2005 20:47:55 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel10.hp.com (Postfix) with ESMTP id C997A256F; Fri, 27 May 2005 17:28:19 -0700 (PDT) Received: from HM701792 (hm701791.cup.hp.com [15.13.133.85]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id FAA12767; Sat, 28 May 2005 05:56:18 +0530 (IST) Message-Id: <200505280026.FAA12767@iconsrv6.india.hp.com> From: "Anil Kumar Reddy" To: "'Iljitsch van Beijnum'" Subject: RE: [dhcwg] Re: purpose of m/o bit Date: Fri, 27 May 2005 17:28:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> Thread-Index: AcVhHgy0xmeslgg2QaeJJ+I31qaP+AB/VZnw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'IETF IPv6 Mailing List' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org : From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] : On Behalf Of Iljitsch van Beijnum : Sent: Wednesday, May 25, 2005 2:43 AM : : [Crossposted to dhcwg even though I'm not on that list, as : people there may be able to add some useful insights.] : All of this, coupled with the fact that, AFAIK, no OS : implements DHCPv6, means that there is essentially zero : experience with DHCPv6 in the operational community. This : means that at this time, there is little point in asking the : operational community what should happen with the M and O bits. FYI - If I am not too late on this: HP-UX supports DHCPv6 implementation - conforming to RFC3315. I don't intend to deviate the topic, but I thought this info may be useful for you with respect to operational community. -- Anil _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri May 27 22:55:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbrU1-0000GF-Js; Fri, 27 May 2005 22:55:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbrTz-0000G6-Rs; Fri, 27 May 2005 22:55:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25809; Fri, 27 May 2005 22:55:25 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbrmu-0000j2-S8; Fri, 27 May 2005 23:15:01 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8FDA0E3; Fri, 27 May 2005 22:52:53 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 22:55:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Semantics of Stateful Bits for the Client Date: Fri, 27 May 2005 22:55:12 -0400 Message-ID: <936A4045C332714F975800409DE0924054164A@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] Semantics of Stateful Bits for the Client Thread-Index: AcVi8a6ejz+kcwHqQ6yX9jDBY2V31wAClV/gAAx3aCA= From: "Bound, Jim" To: "Bernie Volz (volz)" , , X-OriginalArrivalTime: 28 May 2005 02:55:15.0125 (UTC) FILETIME=[AC5C7E50:01C56330] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org =20 > Does anyone really see any value in 1? >=20 > And this is always possible - just don't configure the DHCPv6 server > with any configuration parameters to send out. I don't and never did. I think it odd too. I will share my view of one reason why this happened. Realize my priority is always compromise and move forward, unless it breaks major code base, or significant architecture flaw for the Internet end-to-end model I just cannot accept. Thus, I did support the specs moving forward, and my last statement below says the same thing if we do not change this set of bits. Early on work for IPv6 within the infrastructure driver individuals and from the very first Addrconnf presentation discussion on IPv6 at the IETF, the consenus of that then group was the Internet would be better with stateless and not have go to stateful servers for anything. But, clearly dhc from v4 demonstrated how useful configuration parameters are to a user on a link,and other basic services. But, the consenus then was ok lets make sure we add function to permit some form of stateful configuration (dhc was not even considered at this time by most the eventual mechanism which I never got) for parameters for the link, but separate that option from configuration. Thus, two bits for stateful. One for obtaining addresses, another to obtain configuration parameters. Another more noble reason was the idea to separate stateful address semantics, becuase stateless is the default, from the need for other configuration parameters, and break this perceived problem down into multiple levels of indirection within the link architecture to obtain addresses and configuration parameters as separate functions. I think the entire notion should in theory be changed to just use dhc for addresses+parameters, and let dhc determine, as suggested above with one example. if addresses or parameters are to be provided to the nodes. Prefix delegation is a new function I won't go into in this thread (which I think is wonderful as a note). But we must use caution by removing the ND m+o bits and the affect to ND and Addrconf code base per my other email. Getting consenus on if we change the initial thinking model and a lot of code base (servers, clients, routers etc.), from the non-dhc code affect, on this list I think is key to moving forward. Or we must make the semantics work with the bit-space we have, which I will bet is what we will have to do for multiple reasons and not all technical. My .25 cents, /jim > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > > On Behalf Of Bound, Jim > > Sent: Friday, May 27, 2005 3:24 PM > > To: ipv6@ietf.org; dhcwg@ietf.org > > Subject: [dhcwg] Semantics of Stateful Bits for the Client > >=20 > > If we believe we will inform clients to use or not use dhc and I am > > going to guess all agree with that so we have to multitask here in > > cyberspace. > >=20 > > What semantic conditions do we inform clients about when we=20 > > inform them > > to use dhc via ND packet. > >=20 > > Points from the many mails are as follows. > >=20 > > 1. use dhc only to obtain addresses > >=20 > > 2. use dhc only to obtain configuration parameters > >=20 > > 3. use dhc to do 1 and 2. > >=20 > > Does prefix delegation requires its own condidtion?=20 > >=20 > > Is prefix delegation covered by 1 and then is it dhc=20 > process to decide > > what is done? > >=20 > > /jim > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 28 13:55:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5WY-00064P-C1; Sat, 28 May 2005 13:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5WX-00063p-4H; Sat, 28 May 2005 13:55:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20752; Sat, 28 May 2005 13:54:57 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc5pX-0003j9-1j; Sat, 28 May 2005 14:14:40 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id BB17420000A6; Sat, 28 May 2005 13:54:45 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 May 2005 13:54:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Sat, 28 May 2005 13:54:44 -0400 Message-ID: <936A4045C332714F975800409DE092405416AC@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVjkjpupLshrK2+S0u7/cUCDWVeDAAHAzUA From: "Bound, Jim" To: "Ted Lemon" X-OriginalArrivalTime: 28 May 2005 17:54:45.0748 (UTC) FILETIME=[555C0340:01C563AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org for dhcp yes but for IPv6 it is now widespread in multiple target markets. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; ipv6@ietf.org;=20 > Bernie Volz (volz); Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat May 28 16:03:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc7Ww-0000SQ-Az; Sat, 28 May 2005 16:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc7Wt-0000SI-RZ; Sat, 28 May 2005 16:03:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00311; Sat, 28 May 2005 16:03:29 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc7pt-0006dZ-Mj; Sat, 28 May 2005 16:23:14 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Sat, 28 May 2005 20:03:26 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw13c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Sat, 28 May 2005 20:03:17 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: from mail pickup service by NAEACHRLEX02VA.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Sat, 28 May 2005 16:03:12 -0400 Received: from NAEACHRLEB02.nadsusea.nads.navy.mil ([10.19.119.10]) by NAEACHRLEX02VA.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Sat, 28 May 2005 13:59:35 -0400 Received: from NAEANRFKEB04.nadsusea.nads.navy.mil ([10.16.20.17]) by NAEACHRLEB02.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Sat, 28 May 2005 13:59:35 -0400 Received: from naweprlheb01.nadsuswe.nads.navy.mil ([10.32.118.40]) by NAEANRFKEB04.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Sat, 28 May 2005 13:59:35 -0400 Received: from NAWEPRLHEG04.nadsuswe.nads.navy.mil ([10.32.118.48]) by naweprlheb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Sat, 28 May 2005 07:59:33 -1000 Received: from naweprlhfw02.nmci.navy.mil ([10.32.0.42]) by NAWEPRLHEG04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Sat, 28 May 2005 07:59:32 -1000 Received: from naweprlhms01.nadsuswe.nads.navy.mil by naweprlhfw02.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.32.118.48]) with ESMTP; Sat, 28 May 2005 17:59:32 +0000 Received: from naweprlhfw04c.nmci.navy.mil (naweprlhfw04c.nmci.navy.mil [10.32.0.164]) by naweprlhms01.nadsuswe.nads.navy.mil (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4SHqqx26545 for ; Sat, 28 May 2005 17:52:52 GMT Received: from mx1.spawar.navy.mil ([128.49.251.6]) by naweprlhfw04c.nmci.navy.mil via smtpd (for naweprlhmt01.naweprlhmg.mil [10.32.0.166]) with ESMTP; Sat, 28 May 2005 17:59:31 +0000 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mx1.spawar.navy.mil (8.12.11/8.12.11) with ESMTP id j4SHxP1C027317; Sat, 28 May 2005 10:59:26 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5WZ-000651-RE; Sat, 28 May 2005 13:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5WX-00063p-4H; Sat, 28 May 2005 13:55:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20752; Sat, 28 May 2005 13:54:57 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc5pX-0003j9-1j; Sat, 28 May 2005 14:14:40 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id BB17420000A6; Sat, 28 May 2005 13:54:45 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 May 2005 13:54:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 28 May 2005 13:54:44 -0400 Message-ID: <936A4045C332714F975800409DE092405416AC@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVjkjpupLshrK2+S0u7/cUCDWVeDAAHAzUA From: "Bound, Jim" To: "Ted Lemon" X-OriginalArrivalTime: 28 May 2005 17:54:45.0748 (UTC) FILETIME=[555C0340:01C563AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 4.5, autolearn=not spam) X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org for dhcp yes but for IPv6 it is now widespread in multiple target markets. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; ipv6@ietf.org;=20 > Bernie Volz (volz); Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun May 29 15:05:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcT5u-0006s1-57; Sun, 29 May 2005 15:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcT5r-0006o9-Nc; Sun, 29 May 2005 15:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04378; Sun, 29 May 2005 15:05:02 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcTP6-00036V-NY; Sun, 29 May 2005 15:24:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4TJ4er28690; Sun, 29 May 2005 22:04:41 +0300 Date: Sun, 29 May 2005 22:04:39 +0300 (EEST) From: Pekka Savola To: Erik Nordmark Subject: Re: [dhcwg] RE: purpose of m/o bit In-Reply-To: <429786D1.3050407@sun.com> Message-ID: References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, 27 May 2005, Erik Nordmark wrote: > The issue I see if we recommend that clients (which implement both RFC 3315 > and 3736) always send a Solicit (when some bit is set in the RA telling it to > use DHCP), then such a client will not interoperate with currently deployed > 3736 DHCP servers. > My understanding is that there is some deployment of 3736 DHCP servers (to do > prefix delegation and DNS configuration, etc). > > Do we know that there is zero deployment of 3736 servers today? > > If we need to handle those, it seems like either > - the client needs to try a few Solicits first, and if that fails, try > an Information-Request. (Or try them in parallel??) > - Have some indication in the RA that only 3736 service is available on > the network, so that the client can do the Information-Request only. FWIW, I strongly believe we need to deal with _both_ stateless-only servers *and* clients. I'd also prefer that we would not need to extend RFC3736 to have to include (some) support for handling Solicits. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 30 05:21:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcgSS-0005rM-Iw; Mon, 30 May 2005 05:21:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcgSQ-0005qN-DR; Mon, 30 May 2005 05:21:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29523; Mon, 30 May 2005 05:21:11 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcglm-0004IS-Tw; Mon, 30 May 2005 05:41:16 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j4U9L6i3006464; Mon, 30 May 2005 10:21:06 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA16023; Mon, 30 May 2005 10:21:02 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4U9L1C17807; Mon, 30 May 2005 10:21:01 +0100 Date: Mon, 30 May 2005 10:21:01 +0100 From: Tim Chown To: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] RE: purpose of m/o bit Message-ID: <20050530092101.GT13162@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org References: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, May 27, 2005 at 09:39:52AM -0700, Ted Lemon wrote: > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > >ughh. sorry know of three production servers in use Lucent, HP, and > >Linux version. > > > > That's not what I mean. The point is that it's early days, and > updating servers isn't a hard problem. My point is that I don't > know of any widespread deployments we'd be breaking right now, not > that there are no implementations. We have been looking for a combined DHCPv4/DHCPv6 server platform that could run on Linux or BSD for some time, but have as yet failed to find one. This is for use in a production environment. We are aware of code from NEC and Lucent (but haven't yet seen either) and HP (seems to be for HP/UX only), there's also some Cisco functionality, and finally the sourceforge project (seems dormant for 15 months). We'd be very interested to find an enterprise using DHCPv6 in production, rather than just in a testbed. -- Tim/::1 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 30 09:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dckb6-0005Kk-Ks; Mon, 30 May 2005 09:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dckb3-0005K8-G7; Mon, 30 May 2005 09:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15041; Mon, 30 May 2005 09:46:23 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DckuT-0000qR-M7; Mon, 30 May 2005 10:06:30 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4UDkNmJ062309 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 30 May 2005 15:46:23 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Mon, 30 May 2005 15:46:17 +0200 To: Christian Schild X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 30-mei-2005, at 14:51, Christian Schild wrote: > In my mind RFC3736 is flawed, as it's clients use an > Information-Request message to initiate communication with a > DHCPv6 server and not a Solicit message like RFC3513. > It is _too_ lite. What is it that you want to do for which full DHCPv6 is too heavy but stateless DHCPv6 is too light? > It would be really nice and handy to initiate either stateless or > stateful DHCPv6 with the same message. I don't see a use case for this. As for the client: If a client only asks for configuration information and says it will do rapid-commit, and the server goes along with this (I'm not sure if the server can force more information than what the client asked for, IANADHCPv6Expert), you're basically doing stateless with a Solicit message. On the other hand, if you want to implement a simple client, just build one that does an Information-Request. Server: If you know in advance you're only going to receive Information- Requests, you can implement an RFC 3736 server. However, if you don't know this for sure, you'll have to implement a server that parses the entire DHCPv6 protocol, even if this server doesn't intend giving out stateful information (addresses or prefixes). So what we need is a way to make sure clients only (need to) do Information-Requests in situations where this is appropriate. Then we can build RFC 3736 light clients. If not, at least the servers and possibly also the clients need to implement the full stateful protocol. Also, as an operator I want to know whether a client is going to receive addresses over DHCPv6 in advance rather than have to wait for the client to do the DHCPv6 interaction and see what happened afterwards. > If so, we wouldn't need the M/O bits anymore. Is not needing the O bit a goal? We need the M bit regardless: trying to talk to a DHCPv6 server that isn't there wastes time and bandwidth. > So > 1)we should use M/O as indicators, or > 2)fix RFC3736 to understand Solicit message and then we could drop > M/O. > While it is more work and probably more pain, I'd prefer the latter. Why? These are perfectly well-behaved bits, they don't bite or soil the carpet. :-) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 30 16:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcqnO-0005ap-Ui; Mon, 30 May 2005 16:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcqnO-0005ah-8T; Mon, 30 May 2005 16:23:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11419; Mon, 30 May 2005 16:23:31 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcr6o-0008JE-Vz; Mon, 30 May 2005 16:43:42 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id CBFB9101; Mon, 30 May 2005 16:23:13 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 30 May 2005 16:23:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: purpose of m/o bit Date: Mon, 30 May 2005 16:23:12 -0400 Message-ID: <936A4045C332714F975800409DE0924054176C@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVlKv74ewKcZEY1Tsu6qSHO7xkgVAAKdUNg From: "Bound, Jim" To: "Christian Schild (JOIN Project Team)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 30 May 2005 20:23:13.0707 (UTC) FILETIME=[67BE2FB0:01C56555] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Folks, the purpose of this thread is to define the purpose of the bits for ND and addrconf not resolve how dhc works. We need to finish that first ok. The router is sending m and o bits now. What is their purpose and do they work. If we change them it affects far more than dhc. The thread to how to do this in dhc is most likely truly a dhc wg effort and not an ipv6 wg effort. Again the m or o bit are to inform clients before they even contemplate dhc within an ND packet.=20 Do we need both bits but we need one for them for sure.=20 thanks /jim=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 30 16:48:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcrBs-00083C-UB; Mon, 30 May 2005 16:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcrBi-00082V-Oa; Mon, 30 May 2005 16:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12947; Mon, 30 May 2005 16:48:40 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcrVB-0000MJ-Bt; Mon, 30 May 2005 17:08:51 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4UKmhmJ067473 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 30 May 2005 22:48:44 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1117466173.31317.167.camel@lemy.ipv6.uni-muenster.de> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> <1117466173.31317.167.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03841DBE-5A38-409C-AF44-48F11A1CA400@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [dhcwg] RE: purpose of m/o bit Date: Mon, 30 May 2005 22:48:28 +0200 To: Christian Schild (JOIN Project Team) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On 30-mei-2005, at 17:16, Christian Schild (JOIN Project Team) wrote: >>> It would be really nice and handy to initiate either stateless or >>> stateful DHCPv6 with the same message. >> I don't see a use case for this. > Assume you have a stateless server available on a link and M/O bits > are missing or misconfigured. Ah, ok, the problem is becoming clear to me. You see, I've spent the last 10 years of my life configuring routers. Routers do what I want them to do. Period. But obviously, if you live in an environment where you control the servers, but not the routers, a situation where the router _don't_ do what you want them to may not be unthinkable, or even academic. It's all a matter of perspective. > If there is a client that wants to do stateful DHCPv6 it will at first > send a Solicit message. The stateless server has no idea about that > message type and will not reply. Thus the client has to wait and needs > a timeout before it will send out an Information Request to obtain > other > data. Very true, and not a great situation. However, I don't think reducing functionality elsewhere is the answer. > If now the server would be able to understand the Solicit Message it > could answer immediately (even with the address missing) and the > client does not have to wait. Yes, a solution could be running a server that isn't strictly RFC 3736-only. > My suggestion is just to substitute the Information Request with a > Solicit Request (probably including a Rapid Commit and Option Request > option) in RFC3736. This will make it more compatible with RFC3513 and > both, the stateful and the stateless client, will get an answer > immediately, regardless what kind of server is available. If the dhc working group decides that the current stateless DHCPv6 needs improvement, I think you guys can figure that out on your own. However, speaking as someone who configures those pesky routers, I really want to be able to keep clients from initiating stateful DHCPv6, even if the server would only reply with stateless information anyway. It's a matter of predictability and debugging. (And some things that may or may not matter depending on what direction things take in the future.) >> These are perfectly well-behaved bits, they don't bite or soil the >> carpet. :-) > Actually, as an administrator, they might be a pain. > As stated before, RA and DHCPv6 are different protocols. So when I > want > the hosts in my network to use DHCPv6 it is not sufficient to set up > up the DHCPv6 server (and configure it properly), I also have to > configure every router to send out an M/O bit. For _every_ subnet > btw (which is currently something >500). > So please don't use them as triggers. Using them as a hint is fine, > but > as stated before, this is close to useless. > A little bit more motivation: > In my mind, if capable, a client will always launch DHCPv6 (at least > once) and will try to get additional information, be it an address or > just some other information. It has to ask for some (DNS e.g.) > information anyway. _Especially_ if you switch networks a lot. This is where we disagree. I feel very strongly that it's ESSENTIAL that a network administrator has a way to make hosts that aren't specially configured to act one way or another NOT do DHCPv6. If we assume the M/O bits will be used for this (we can come up with something new, of course) that means that if both these bits are set to zero, a host without special configuration does NOT do DHCPv6. I agree that in large networks, it's probably unpleasant to have to set up M and O bits properly on every router on every subnet. On the other hand, you need to install a DHCP server, or, more likely, DHCPv6 relaying, on every subnet anyway, so we shouldn't blow this out of proportion either. But it would be very helpful if routers could set the M and O bits automatically depending on some other relevant configuration. For instance, assuming that it's always possible to set the bits to a specific value manually, the default value could depend on wheter the router itself is configured to be a DHCPv6 server, or is configured as a DHCPv6 relay. In the latter case, the router could even temporarily poll the server and clear the bits if the server is dead. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jun 01 21:53:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddeto-0006gy-CW; Wed, 01 Jun 2005 21:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcReV-0005ZS-BO for dhcwg@megatron.ietf.org; Sun, 29 May 2005 13:32:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28250 for ; Sun, 29 May 2005 13:32:40 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcRxj-0001KB-Vg for dhcwg@ietf.org; Sun, 29 May 2005 13:52:37 -0400 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DcReT-000EQs-7W for dhcwg@ietf.org; Sun, 29 May 2005 13:32:41 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4THWd420650 for ; Sun, 29 May 2005 10:32:40 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sun, 29 May 2005 10:32:39 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Wed, 01 Jun 2005 21:53:30 -0400 Subject: [dhcwg] DNAv4 Router implementation survey X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org In IETF last call for the DNAv4 document, a question was raised about the behavior of routers with respect to ARP Probes (ARP Request with sender address = 0.0.0.0) If you have been involved in a router implementation, please answer the following questions and send the answers to me: a. After booting and configuring interface addresses, does your implementation answer ARP Probes for its address? b. When a static IPv4 address is assigned on an interface, what does your implementation do prior to using the address? 1. Does nothing, just uses the address. 2. Sends an ARP Announcement (otherwise known as "Gratuitous ARP") 3. Broadcasts an ARP Reply 4. Sends an ARP Probe (ARP Request for the address, with sender address = 0.0.0.0) 5. Behaves as specified in draft-cheshire-ipv4-acd-03.txt (multiple ARP probes followed by ARP Announcement) c. If your implementation behaves as specified in the acd document, how does it behave if it receives an ARP probe for its address during the period in which it is probing for that same address? 1. Interprets the probe as indication of an address conflict and stops using the address. 2. Logs the conflict but does not stop using the address. 3. Ignores the probe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jun 01 21:53:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddeto-0006hq-R0; Wed, 01 Jun 2005 21:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjkC-0000QJ-Nv; Mon, 30 May 2005 08:51:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12310; Mon, 30 May 2005 08:51:47 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dck3b-0008ML-CX; Mon, 30 May 2005 09:11:52 -0400 Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.3/8.12.9) with ESMTP id j4UCpjs7020988 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 May 2005 14:51:45 +0200 (CEST) Subject: Re: [dhcwg] RE: purpose of m/o bit From: Christian Schild To: dhcwg@ietf.org, ipv6@ietf.org In-Reply-To: <429786D1.3050407@sun.com> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> Content-Type: text/plain Date: Mon, 30 May 2005 14:51:44 +0200 Message-Id: <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.3.101mdk Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Jun 2005 21:53:30 -0400 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Am Freitag, den 27.05.2005, 13:45 -0700 schrieb Erik Nordmark: > The issue I see if we recommend that clients (which implement both > RFC > 3315 and 3736) always send a Solicit (when some bit is set in the RA > telling it to use DHCP), then such a client will not interoperate > with > currently deployed 3736 DHCP servers. > My understanding is that there is some deployment of 3736 DHCP > servers > (to do prefix delegation and DNS configuration, etc). In my mind RFC3736 is flawed, as it's clients use an Information-Request message to initiate communication with a DHCPv6 server and not a Solicit message like RFC3513. It is _too_ lite. It would be really nice and handy to initiate either stateless or stateful DHCPv6 with the same message. If so, we wouldn't need the M/O bits anymore. In this case the client would simply initiate a(n Information) Request message and would get all the information that are available on the link, including an address or not. In the current state -- being stateful and stateless DHCPv6 two independent protocols -- we need the M/O bits as indicators for what is available on the link and to reduce the message count. So 1)we should use M/O as indicators, or 2)fix RFC3736 to understand Solicit message and then we could drop M/O. While it is more work and probably more pain, I'd prefer the latter. So long, Christian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jun 01 21:53:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddetp-0006ig-9A; Wed, 01 Jun 2005 21:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcm04-0005QP-Rp; Mon, 30 May 2005 11:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21298; Mon, 30 May 2005 11:16:18 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcmJU-0002Ok-Jv; Mon, 30 May 2005 11:36:26 -0400 Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.3/8.12.9) with ESMTP id j4UFGEqH023032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 May 2005 17:16:18 +0200 (CEST) Subject: Re: [dhcwg] RE: purpose of m/o bit From: "Christian Schild (JOIN Project Team)" To: Iljitsch van Beijnum In-Reply-To: <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> Content-Type: text/plain Date: Mon, 30 May 2005 17:16:12 +0200 Message-Id: <1117466173.31317.167.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.3.101mdk Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Jun 2005 21:53:30 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Am Montag, den 30.05.2005, 15:46 +0200 schrieb Iljitsch van Beijnum: > On 30-mei-2005, at 14:51, Christian Schild wrote: > > > In my mind RFC3736 is flawed, as it's clients use an > > Information-Request message to initiate communication with a > > DHCPv6 server and not a Solicit message like RFC3513. > > It is _too_ lite. > > What is it that you want to do for which full DHCPv6 is too heavy but > stateless DHCPv6 is too light? > > > It would be really nice and handy to initiate either stateless or > > stateful DHCPv6 with the same message. > > I don't see a use case for this. Assume you have a stateless server available on a link and M/O bits are missing or misconfigured. If there is a client that wants to do stateful DHCPv6 it will at first send a Solicit message. The stateless server has no idea about that message type and will not reply. Thus the client has to wait and needs a timeout before it will send out an Information Request to obtain other data. If now the server would be able to understand the Solicit Message it could answer immediately (even with the address missing) and the client does not have to wait. > As for the client: > > If a client only asks for configuration information and says it will > do rapid-commit, and the server goes along with this (I'm not sure if > the server can force more information than what the client asked for, > IANADHCPv6Expert), you're basically doing stateless with a Solicit > message. > > On the other hand, if you want to implement a simple client, just > build one that does an Information-Request. > > Server: > > If you know in advance you're only going to receive Information- > Requests, you can implement an RFC 3736 server. > > However, if you don't know this for sure, you'll have to implement a > server that parses the entire DHCPv6 protocol, even if this server > doesn't intend giving out stateful information (addresses or prefixes). You don't have to. My suggestion is just to substitute the Information Request with a Solicit Request (probably including a Rapid Commit and Option Request option) in RFC3736. This will make it more compatible with RFC3513 and both, the stateful and the stateless client, will get an answer immediately, regardless what kind of server is available. > So what we need is a way to make sure clients only (need to) do > Information-Requests in situations where this is appropriate. Then we > can build RFC 3736 light clients. If not, at least the servers and > possibly also the clients need to implement the full stateful protocol. > > Also, as an operator I want to know whether a client is going to > receive addresses over DHCPv6 in advance rather than have to wait for > the client to do the DHCPv6 interaction and see what happened > afterwards. > > > If so, we wouldn't need the M/O bits anymore. > > Is not needing the O bit a goal? > > We need the M bit regardless: trying to talk to a DHCPv6 server that > isn't there wastes time and bandwidth. > > > So > > 1)we should use M/O as indicators, or > > 2)fix RFC3736 to understand Solicit message and then we could drop > > M/O. > > > While it is more work and probably more pain, I'd prefer the latter. > > Why? > > These are perfectly well-behaved bits, they don't bite or soil the > carpet. :-) Actually, as an administrator, they might be a pain. As stated before, RA and DHCPv6 are different protocols. So when I want the hosts in my network to use DHCPv6 it is not sufficient to set up up the DHCPv6 server (and configure it properly), I also have to configure every router to send out an M/O bit. For _every_ subnet btw (which is currently something >500). So please don't use them as triggers. Using them as a hint is fine, but as stated before, this is close to useless. A little bit more motivation: In my mind, if capable, a client will always launch DHCPv6 (at least once) and will try to get additional information, be it an address or just some other information. It has to ask for some (DNS e.g.) information anyway. _Especially_ if you switch networks a lot. Christian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg