From dhcwg-admin@ietf.org Sat Mar 1 00:13:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24163; Sat, 1 Mar 2003 00:13:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h215Mep21973; Sat, 1 Mar 2003 00:22:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h215KDp21918 for ; Sat, 1 Mar 2003 00:20:13 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24108 for ; Sat, 1 Mar 2003 00:10:51 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h2159XJ02567; Fri, 28 Feb 2003 23:09:35 -0600 (CST) Date: Fri, 28 Feb 2003 23:12:46 -0600 Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Ralph Droms To: Jun Xie From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030228202840.00b00300@mira-sjcm-2.cisco.com> Message-Id: <7073EDAA-4BA4-11D7-9787-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Caching name server is only one special kind of name servers. > I don't think the option is limited to specify caching name servers > only. > I think domain name server is more general and appropriate here. The purpose of this option is to tell the client where it should send DNS lookups for final resolution. Not all name servers are configured to do recursive name resolution for nodes with stub resolvers. Some name servers, for example, only serve the zones for which they are primary or secondary, and refuse requests for recursive lookups. So it is actually meaningful to make a distinction here. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailman-admin@ietf.org Sat Mar 1 11:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09929 for ; Sat, 1 Mar 2003 11:01:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21GAwp09337 for ; Sat, 1 Mar 2003 11:10:58 -0500 Date: Sat, 01 Mar 2003 11:10:58 -0500 Message-ID: <20030301161058.26394.38247.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Sat Mar 1 14:15:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15218; Sat, 1 Mar 2003 14:15:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21JOQp27490; Sat, 1 Mar 2003 14:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21JNYp27468 for ; Sat, 1 Mar 2003 14:23:34 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15210 for ; Sat, 1 Mar 2003 14:13:54 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h21JFeP7019959; Sat, 1 Mar 2003 11:15:40 -0800 (PST) Received: from C1840447-A.cisco.com (sjc-vpn1-747.cisco.com [10.21.98.235]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEP35726; Sat, 1 Mar 2003 11:10:51 -0800 (PST) Message-Id: <4.3.2.7.2.20030301110208.00adf460@mira-sjcm-2.cisco.com> X-Sender: junxie@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 01 Mar 2003 11:17:29 -0800 To: Ted Lemon From: Jun Xie Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options Cc: dhcwg@ietf.org, Ralph Droms In-Reply-To: <7073EDAA-4BA4-11D7-9787-00039367340A@nominum.com> References: <4.3.2.7.2.20030228202840.00b00300@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:12 PM 2/28/03 -0600, Ted Lemon wrote: >>Caching name server is only one special kind of name servers. >>I don't think the option is limited to specify caching name servers only. >>I think domain name server is more general and appropriate here. > >The purpose of this option is to tell the client where it should send DNS >lookups for final resolution. Not all name servers are configured to do >recursive name resolution for nodes with stub resolvers. Some name >servers, for example, only serve the zones for which they are primary or >secondary, and refuse requests for recursive lookups. So it is actually >meaningful to make a distinction here. Nothing prevents a stub resolver from sending further queries to the server referred by an iterative server, although many implementations don't do it. In an isolated site, I think the option can also be used to configure name servers that serve the local zones only, for local DHCP clients. Since those clients can go beyond the site _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Mar 1 14:31:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15505; Sat, 1 Mar 2003 14:31:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21Je7p28764; Sat, 1 Mar 2003 14:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21Jdfp28661 for ; Sat, 1 Mar 2003 14:39:41 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15408 for ; Sat, 1 Mar 2003 14:30:01 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h21JVfHK015642; Sat, 1 Mar 2003 11:31:41 -0800 (PST) Received: from C1840447-A.cisco.com (sjc-vpn1-747.cisco.com [10.21.98.235]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEP36091; Sat, 1 Mar 2003 11:26:55 -0800 (PST) Message-Id: <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com> X-Sender: junxie@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 01 Mar 2003 11:29:34 -0800 To: Ted Lemon From: Jun Xie Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options Cc: dhcwg@ietf.org, Ralph Droms In-Reply-To: <7073EDAA-4BA4-11D7-9787-00039367340A@nominum.com> References: <4.3.2.7.2.20030228202840.00b00300@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:12 PM 2/28/03 -0600, Ted Lemon wrote: >>Caching name server is only one special kind of name servers. >>I don't think the option is limited to specify caching name servers only. >>I think domain name server is more general and appropriate here. > >The purpose of this option is to tell the client where it should send DNS >lookups for final resolution. Not all name servers are configured to do >recursive name resolution for nodes with stub resolvers. Some name >servers, for example, only serve the zones for which they are primary or >secondary, and refuse requests for recursive lookups. So it is actually >meaningful to make a distinction here. Nothing prevents a stub resolver from sending further queries to the server referred by an iterative server, although many implementations don't do it. In an isolated site, I think the option can also be used to configure name servers that serve the local zones only, for local DHCP clients. Since those clients can not go beyond the site, the answers they get from the servers are final resolution for them. If the option really represents name servers that can do recursive resolution, this should be clearly specified. Even in this case, "name server" is still more appropriate than "resolver" for the name of the option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Mar 1 23:07:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24155; Sat, 1 Mar 2003 23:07:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224GOp25448; Sat, 1 Mar 2003 23:16:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224DXp25375 for ; Sat, 1 Mar 2003 23:13:33 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24137 for ; Sat, 1 Mar 2003 23:03:43 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h2245gd03194; Sat, 1 Mar 2003 22:05:42 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h2245gb24450; Sat, 1 Mar 2003 22:05:42 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Sat, 1 Mar 2003 22:05:42 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Jun Xie'" , Ted Lemon , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Revision of DHCPv6 DNS configuration options Date: Sat, 1 Mar 2003 22:04:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E070.C1B517E8" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2E070.C1B517E8 Content-Type: text/plain; charset="ISO-8859-1" Ah ... what's in a name? I too would have preferred the original name for the option - "Domain Name Server". Perhaps I missed it, but what was the reason for this change? - Bernie -----Original Message----- From: Jun Xie [mailto:junxie@cisco.com] Sent: Saturday, March 01, 2003 2:30 PM To: Ted Lemon Cc: dhcwg@ietf.org; Ralph Droms Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options At 11:12 PM 2/28/03 -0600, Ted Lemon wrote: >>Caching name server is only one special kind of name servers. >>I don't think the option is limited to specify caching name servers only. >>I think domain name server is more general and appropriate here. > >The purpose of this option is to tell the client where it should send DNS >lookups for final resolution. Not all name servers are configured to do >recursive name resolution for nodes with stub resolvers. Some name >servers, for example, only serve the zones for which they are primary or >secondary, and refuse requests for recursive lookups. So it is actually >meaningful to make a distinction here. Nothing prevents a stub resolver from sending further queries to the server referred by an iterative server, although many implementations don't do it. In an isolated site, I think the option can also be used to configure name servers that serve the local zones only, for local DHCP clients. Since those clients can not go beyond the site, the answers they get from the servers are final resolution for them. If the option really represents name servers that can do recursive resolution, this should be clearly specified. Even in this case, "name server" is still more appropriate than "resolver" for the name of the option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2E070.C1B517E8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Revision of DHCPv6 DNS configuration options

Ah ... what's in a name?

I too would have preferred the original name for the = option - "Domain Name Server".

Perhaps I missed it, but what was the reason for this = change?

- Bernie

-----Original Message-----
From: Jun Xie [mailto:junxie@cisco.com]
Sent: Saturday, March 01, 2003 2:30 PM
To: Ted Lemon
Cc: dhcwg@ietf.org; Ralph Droms
Subject: Re: [dhcwg] Revision of DHCPv6 DNS = configuration options


At 11:12 PM 2/28/03 -0600, Ted Lemon wrote:
>>Caching name server is only one special kind = of name servers.
>>I don't think the option is limited to = specify caching name servers only.
>>I think domain name server is more general = and appropriate here.
>
>The purpose of this option is to tell the client = where it should send DNS
>lookups for final resolution.   Not = all name servers are configured to do
>recursive name resolution for nodes with stub = resolvers.   Some name
>servers, for example, only serve the zones for = which they are primary or
>secondary, and refuse requests for recursive = lookups.   So it is actually
>meaningful to make a distinction here.

Nothing prevents a stub resolver from sending further = queries to the server
referred by an iterative server, although many = implementations don't do it.
In an isolated site, I think the option can also be = used to configure name
servers that serve the local zones only, for local = DHCP clients. Since
those clients can not go beyond the site, the = answers they get from the
servers are final resolution for them. If the option = really represents name
servers that can do recursive resolution, this = should be clearly specified.
Even in this case, "name server" is still = more appropriate than "resolver"
for the name of the option.

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

------_=_NextPart_001_01C2E070.C1B517E8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Mar 2 20:45:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23419; Sun, 2 Mar 2003 20:45:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h231spp17332; Sun, 2 Mar 2003 20:54:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h231rfp17248 for ; Sun, 2 Mar 2003 20:53:41 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23389 for ; Sun, 2 Mar 2003 20:43:25 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h231fqJ01752; Sun, 2 Mar 2003 19:41:52 -0600 (CST) Date: Sun, 2 Mar 2003 19:45:36 -0600 Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Ralph Droms To: Jun Xie From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030301110208.00adf460@mira-sjcm-2.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Since > those clients can not go beyond the site, the answers they get from the > servers are final resolution for them. If the option really represents > name > servers that can do recursive resolution, this should be clearly > specified. > Even in this case, "name server" is still more appropriate than > "resolver" > for the name of the option. I don't think it's useful for us to continue discussing this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Mar 2 23:13:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25888; Sun, 2 Mar 2003 23:13:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234N6p27432; Sun, 2 Mar 2003 23:23:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234LGp27369 for ; Sun, 2 Mar 2003 23:21:16 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25841 for ; Sun, 2 Mar 2003 23:10:56 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h234BjO09192; Mon, 3 Mar 2003 11:11:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h234BUo26091; Mon, 3 Mar 2003 11:11:30 +0700 (ICT) From: Robert Elz To: Jun Xie cc: Ted Lemon , dhcwg@ietf.org, Ralph Droms Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options In-Reply-To: <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030228202840.00b00300@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Mar 2003 11:11:30 +0700 Message-ID: <26089.1046664690@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Sat, 01 Mar 2003 11:29:34 -0800 From: Jun Xie Message-ID: <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com> | Nothing prevents a stub resolver from sending further queries to the server | referred by an iterative server, No, but the point of the option is (or should be) to provide the addresses of "things" for which that will not be required - that is, things which will do recursive resolution for the (stub) resolver. If the stub resolver is able to do iterative resolution, then all it needs is a list of the root servers, and I really don't believe this option should be used for that - and it should be made clear that that isn't what should be sent in this option. It is truly unfortunate that the DNS has never created a name for this "thing" which has stuck - "DNS server" was used originally, but many, rightly I feel, object to that one as being too vague - a DNS server isn't required to do recursive resolution, here we want a thing which will do recursive resolution (at least for the clients being instructed to use it) and so calling it a "DNS Server" isn't really the best idea. Calling it a "resolver" is no better however, the resolver is the thing that is going to be using this information really, and while a recursive server can be thought of as a resolver, which gets its query passed to it using DNS protocols, rather than the more usual function calls, it is still a stretch on most people's interpretation of the term - that is, using it suggests to people something other than what is intended. I'd suggest using some label that is neither of those - and since the DNS community has failed to produce a name for this thing, I see no reason for this WG to not just go ahead and pick a suitable name, and define it. With any luck, it can then transfer itself into the DNS lexicon, and the whole DNS community will be grateful (trying to continually find some good term which will unambiguously describe the thing that is of interest here is a recurring nightmare - and has caused misunderstandings quite often in the DNS world). I have no particular suggestion to offer (if I had a really good one, then perhaps everyone would be using it by now), but something along the lines of "DNS cache server" or "DNS caching resolver" or perhaps just "DNS cache". What is clear however, is that whatever name is used (including DNS server and DNS resolver) its function needs to be clearly spelled out in this doc - either this will be a new term, or the re-use of an ambiguous one, and so this doc cannot simply rely upon saying "The address of a DNS XXX goes here" and just assume that what a "DNS XXX" is will be clear to everyone (and once more for emphasis, this applies whatever is substituted for XXX). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Mar 2 23:26:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26179; Sun, 2 Mar 2003 23:26:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234aAp28044; Sun, 2 Mar 2003 23:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h229B1p19455 for ; Sun, 2 Mar 2003 04:11:01 -0500 Received: from raven.ecs.soton.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08552 for ; Sun, 2 Mar 2003 04:01:04 -0500 (EST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA23236; Sun, 2 Mar 2003 09:03:03 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA09884; Sun, 2 Mar 2003 09:03:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h22932003817; Sun, 2 Mar 2003 09:03:02 GMT Date: Sun, 2 Mar 2003 09:03:02 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com, dhcwg@ietf.org Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt] Message-ID: <20030302090302.GD3724@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com, dhcwg@ietf.org References: <20030227155714.A28766@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030227155714.A28766@sverresborg.uninett.no> User-Agent: Mutt/1.4i Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, Feb 27, 2003 at 03:57:14PM +0100, Tim Chown wrote: > > On Thu, Feb 27, 2003 at 09:35:52AM +0200, Pekka Savola wrote: > > > > I hear many (two sets of groups) are implementing DHCPv6 either for: > > - configuration parameters > > - prefix delegation (for the lack of alternatives) > > I would just add a "flag wave" for 6NET's Deliverable D3.2.3 which reports > on DHCPv6 implementations which may be of interest to people here [apologies > if a pointer has already been posted - just dipping in :] Ooops - some people asked for the URL for this DHCPv6 implementation and test report - it's at: http://www.6net.org/publications/deliverables/D3.2.3.pdf Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 3 06:47:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18458; Mon, 3 Mar 2003 06:47:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23BvXp08585; Mon, 3 Mar 2003 06:57:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Burp08391 for ; Mon, 3 Mar 2003 06:56:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18019; Mon, 3 Mar 2003 06:46:26 -0500 (EST) Message-Id: <200303031146.GAA18019@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 03 Mar 2003 06:46:26 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-05.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-05.txt,.pdf Pages : 13 Date : 2003-2-28 This document describes the DHCP option to allow iSNS clients using DHCP for IPv4 to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-05.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-isnsoption-05.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: <2003-2-28125116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125116.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 3 14:22:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08587; Mon, 3 Mar 2003 14:22:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23JWjp18125; Mon, 3 Mar 2003 14:32:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23JVPp18079 for ; Mon, 3 Mar 2003 14:31:25 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08535 for ; Mon, 3 Mar 2003 14:20:48 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h23JMIJR009596; Mon, 3 Mar 2003 14:22:18 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by goblet.cisco.com (Mirapoint) with ESMTP id ACS57566; Mon, 3 Mar 2003 14:22:17 -0500 (EST) Message-Id: <4.3.2.7.2.20030303135757.0255f9b0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Mar 2003 14:22:16 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Changes to create draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, Here is mail detailing the changes made to draft-ietf-dhc-failover-11.txt to yield draft-ietf-dhc-failover-12.txt. In most cases considerable changes were made to the indicated sections, so that it was not possible to say "this word changed to that word", but rather the entire section needs to be re-read to grasp the essence of the change. ------------------------------------------------------------------- During the last IETF in Atlanta, a discussion was held with several folks about problems in the DHCP failover protocol and its description. In attendance were: Scanner Luce scanner@nominum.com Bernie Volz Bernie.Volz@am1.ericsson.se Mark Stapp mjs@cisco.com Kim Kinnear kkinnear@cisco.com We primarily discussed issues encountered by Scanner during his implementation of the failover protocol, and first raised at a meeting with several people during the Summer 2002 IETF. Thanks to Bernie Volz for comments and additions to an earlier version of these notes. Some of his additions I've simply placed into the text, but I've left one comment explicit since we may want to discuss it further. The action plan for failover at this point is: (x) a. Circulate these notes to the DHCP list. (x) b. Accept comments. (x) c. Update the failover draft by the end of February. --> c-1. Circulate email concerning changes made. d. Consider whether we need another WG last call based on these changes. This email is step C-1. Changes made to the failover draft: ----------------------------------- While the discussion ranged over several topics, the action items boiled down to the following: 1. Connection establishment changes: a. There MUST be one endpoint failover relationship (i.e., between two servers). b. There SHOULD be one relationship per partner, but this is not a requirement. We determined there was little value in having the same two servers be involved in two relationships (in general). So, having one server be primary for some pools and secondary for others where the partner has opposite roles is really not necessary and makes little sense. Especially now that load balancing exists and the primary and secondary are almost equal (the primary just breaks ties). c. There SHOULD be only one port in use for failover traffic. d. The TCP connection from the secondary server to the primary server is dropped by the secondary server or is dropped by the primary server in the event that both servers end up connecting at the same time. We need a strategy to handle the case where two connections are done at the same time (primary -> secondary; secondary -> primary). The role is simply that the connection that the primary initiated is the one that is kept. So, the primary drops the connection it ACCEPTed from the secondary and the secondary drops the connection on which it CONNECTed to the primary. Modifications were made to implement these changes to: Definition of failover endpoint. Section 5.1.1 Failover endpoints Section 8. Connection Management Section 8.1 Connection granularity Section 8.2 Creating the TCP connection 2. Remove paragraph 4 from Section 7.1.3 (from the BNDUPD conflict section). This paragraph turns out to add as opposed to remove confusion. Modifications were made to implement this change by: Removing paragraph 4 from Section 7.1.3. 3. Consider adding pseudo-code for the MCLT logic (which Scanner has offered to contribute, since he felt this would be helpful.) I'll include anything I get in this regard. No modifications were made in this case, because I received no pseudo-code to add. 4. Review sequence diagrams for accuracy. These were all reviewed, but no changes were made as no problems were found. If someone has problems with these sequence diagrams, please send me specific information about the problem, and I'll be glad to fix it. 5. The failover partners can run in two different modes -- time sync mode, or time skew mode. In time sync mode, still send the time, and the receiving server can be itself be in one of two modes -- time correction mode (to handle time drift) or time rejection mode (which will reject packets with a time that is "too wrong") in them. Bernie added: One point is that whichever mode one is in, one must allow some small drift in time when doing time based comparisons. For example, lease expirations may easily be off by 1 second just because of the time that elapsed between when a packet was sent and received (a very small fraction of time must elapse for this to potentially happen). I think that was more the issue that we need to make clear - time checks need to be somewhat soft rather than absolute? But I agree that servers may chose to require the time to be "in sync" or can chose to do time corrections. Note that we have found problems in not accommodating time skew; if the servers require the time to be in sync and continue running (but refuse to communicate) bad things sometimes happen (especially if the servers assume partner-down state). This can happen because step 6 in section 9.3.2 allows two actions. We may want to consider exactly what it means for the partner to be "down"; for example if the partner is up but a connection can not be established because the time-skew it out of range, then it may be better to have one server wait (typically the one that was down the longest?). Modifications were made to implement this change by changing: Section 5.10 Time synchronization between servers 6. The client-last-transaction-time should not be remembered if the packet is dropped due to the server being in the wrong failover state to respond to DHCP client packets. This was implicit in the previous versions of the draft, but not clearly stated. Modifications were made to implement this change by changing: Section 9.2 Server State Transitions 7. Contact information was changed, and some dates were updated to 2003. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 3 16:22:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13276; Mon, 3 Mar 2003 16:22:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23LWVp27519; Mon, 3 Mar 2003 16:32:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23LVRp27481 for ; Mon, 3 Mar 2003 16:31:27 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13251 for ; Mon, 3 Mar 2003 16:20:47 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h23LMIJR018281; Mon, 3 Mar 2003 16:22:18 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (rtp-vpn2-958.cisco.com [10.82.243.190]) by goblet.cisco.com (Mirapoint) with ESMTP id ACS60723; Mon, 3 Mar 2003 16:22:14 -0500 (EST) Message-Id: <4.3.2.7.2.20030303161952.025645b8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Mar 2003 16:22:10 -0500 To: Kim Kinnear , dhcwg@ietf.org From: Kim Kinnear In-Reply-To: <4.3.2.7.2.20030303135757.0255f9b0@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: Changes to create draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Well, the submission deadline *used* to be 5pm, but I guess that was only when it was on Friday. Sigh, I should read the fine print next time. So, the -12 version of the draft will not be available until I find someplace else to stash it so you can read it. Ditto for the leasequery draft that I was about to submit. More later, Kim At 02:22 PM 3/3/2003, Kim Kinnear wrote: >Folks, > >Here is mail detailing the changes made to >draft-ietf-dhc-failover-11.txt to yield >draft-ietf-dhc-failover-12.txt. In most cases considerable >changes were made to the indicated sections, so that it was not >possible to say "this word changed to that word", but rather the >entire section needs to be re-read to grasp the essence of the >change. > >------------------------------------------------------------------- > >During the last IETF in Atlanta, a discussion was held with several >folks about problems in the DHCP failover protocol and its description. >In attendance were: > >Scanner Luce scanner@nominum.com >Bernie Volz Bernie.Volz@am1.ericsson.se >Mark Stapp mjs@cisco.com >Kim Kinnear kkinnear@cisco.com > >We primarily discussed issues encountered by Scanner during his >implementation of the failover protocol, and first raised at a >meeting with several people during the Summer 2002 IETF. > >Thanks to Bernie Volz for comments and additions to an earlier >version of these notes. Some of his additions I've simply placed >into the text, but I've left one comment explicit since we may >want to discuss it further. > >The action plan for failover at this point is: > > (x) a. Circulate these notes to the DHCP list. > > (x) b. Accept comments. > > (x) c. Update the failover draft by the end of February. > >--> c-1. Circulate email concerning changes made. > > d. Consider whether we need another WG last call based > on these changes. > >This email is step C-1. > >Changes made to the failover draft: >----------------------------------- > >While the discussion ranged over several topics, the action items >boiled down to the following: > >1. Connection establishment changes: > > a. There MUST be one endpoint failover relationship > (i.e., between two servers). > > b. There SHOULD be one relationship per partner, but > this is not a requirement. > > We determined there was little value in having the same > two servers be involved in two relationships (in > general). So, having one server be primary for some > pools and secondary for others where the partner has > opposite roles is really not necessary and makes little > sense. Especially now that load balancing exists and the > primary and secondary are almost equal (the primary just > breaks ties). > > c. There SHOULD be only one port in use for failover > traffic. > > d. The TCP connection from the secondary server to the > primary server is dropped by the secondary server > or is dropped by the primary server in the event that both > servers end up connecting at the same time. > > We need a strategy to handle the case where two > connections are done at the same time (primary -> > secondary; secondary -> primary). The role is simply > that the connection that the primary initiated is the one > that is kept. So, the primary drops the connection it > ACCEPTed from the secondary and the secondary drops the > connection on which it CONNECTed to the primary. > > Modifications were made to implement these changes to: > > Definition of failover endpoint. > > Section 5.1.1 Failover endpoints > > Section 8. Connection Management > > Section 8.1 Connection granularity > > Section 8.2 Creating the TCP connection > >2. Remove paragraph 4 from Section 7.1.3 (from the BNDUPD >conflict section). This paragraph turns out to add as opposed to >remove confusion. > > Modifications were made to implement this change by: > > Removing paragraph 4 from Section 7.1.3. > >3. Consider adding pseudo-code for the MCLT logic (which Scanner >has offered to contribute, since he felt this would be helpful.) >I'll include anything I get in this regard. > > No modifications were made in this case, because I received > no pseudo-code to add. > >4. Review sequence diagrams for accuracy. > > These were all reviewed, but no changes were made as no problems > were found. If someone has problems with these sequence diagrams, > please send me specific information about the problem, and I'll > be glad to fix it. > >5. The failover partners can run in two different modes -- time >sync mode, or time skew mode. In time sync mode, still send the >time, and the receiving server can be itself be in one of two >modes -- time correction mode (to handle time drift) or time >rejection mode (which will reject packets with a time that is >"too wrong") in them. > >Bernie added: > > One point is that whichever mode one is in, one must > allow some small drift in time when doing time based > comparisons. For example, lease expirations may easily > be off by 1 second just because of the time that elapsed > between when a packet was sent and received (a very small > fraction of time must elapse for this to potentially > happen). I think that was more the issue that we need to > make clear - time checks need to be somewhat soft rather > than absolute? But I agree that servers may chose to > require the time to be "in sync" or can chose to do time > corrections. > > Note that we have found problems in not accommodating > time skew; if the servers require the time to be in sync > and continue running (but refuse to communicate) bad > things sometimes happen (especially if the servers assume > partner-down state). This can happen because step 6 in > section 9.3.2 allows two actions. We may want to > consider exactly what it means for the partner to be > "down"; for example if the partner is up but a connection > can not be established because the time-skew it out of > range, then it may be better to have one server wait > (typically the one that was down the longest?). > > Modifications were made to implement this change by changing: > > Section 5.10 Time synchronization between servers > >6. The client-last-transaction-time should not be remembered if >the packet is dropped due to the server being in the wrong >failover state to respond to DHCP client packets. This was >implicit in the previous versions of the draft, but not clearly >stated. > > Modifications were made to implement this change by changing: > > Section 9.2 Server State Transitions > >7. Contact information was changed, and some dates were updated >to 2003. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 07:33:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15202; Tue, 4 Mar 2003 07:33:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24ChNp32116; Tue, 4 Mar 2003 07:43:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cbxp31855 for ; Tue, 4 Mar 2003 07:37:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14236; Tue, 4 Mar 2003 07:27:01 -0500 (EST) Message-Id: <200303041227.HAA14236@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Mar 2003 07:27:01 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : NIS Configuration Options for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Pages : 6 Date : 2003-3-3 This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-nisconfig-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-dhcpv6-opt-nisconfig-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: <2003-3-3144511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144511.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 07:33:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15248; Tue, 4 Mar 2003 07:33:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Ci2p32147; Tue, 4 Mar 2003 07:44:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cc3p31863 for ; Tue, 4 Mar 2003 07:38:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14254; Tue, 4 Mar 2003 07:27:06 -0500 (EST) Message-Id: <200303041227.HAA14254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Mar 2003 07:27:06 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Time Configuration Options for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Pages : 7 Date : 2003-3-3 This document describes the options for Time related configuration information in DHCPv6: NTP Servers and Timezone specifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-timeconfig-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-dhcpv6-opt-timeconfig-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: <2003-3-3144521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144521.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 12:13:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01952; Tue, 4 Mar 2003 12:13:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HNOp23518; Tue, 4 Mar 2003 12:23:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HMNp23464 for ; Tue, 4 Mar 2003 12:22:23 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01900 for ; Tue, 4 Mar 2003 12:11:18 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24HD857017795; Tue, 4 Mar 2003 09:13:08 -0800 (PST) Date: Tue, 4 Mar 2003 12:13:08 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-isnsoption-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , draft-ietf-dhc-isnsoption-04.txt: Accept with editorial changes; draft-ietf-dhc-isnsoption-05.txt has been published and is ready for IESG review - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 12:13:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01997; Tue, 4 Mar 2003 12:13:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HO2p23566; Tue, 4 Mar 2003 12:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HNNp23512 for ; Tue, 4 Mar 2003 12:23:23 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01931 for ; Tue, 4 Mar 2003 12:12:18 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24HEL57018688 for ; Tue, 4 Mar 2003 09:14:21 -0800 (PST) Date: Tue, 4 Mar 2003 12:14:21 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-dhcpv6-loadb-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , draft-ietf-dhc-dhcpv6-loadb-02.txt: No comments were received during the WG last call - if you support the acceptance of this specification without changes, please respond as soon as possible to the dhc WG mailing list _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 12:16:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02172; Tue, 4 Mar 2003 12:16:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HR2p23778; Tue, 4 Mar 2003 12:27:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HPHp23657 for ; Tue, 4 Mar 2003 12:25:17 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02048 for ; Tue, 4 Mar 2003 12:14:12 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24HGF57020095; Tue, 4 Mar 2003 09:16:15 -0800 (PST) Date: Tue, 4 Mar 2003 12:16:14 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Results ofrecent WG last calls Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt: Accept with editorial changes; draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt, which includes a summary of changes made to the specification as a result of input received during WG last call, has been submitted for publication and will be ready for IESG review draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt: Accept with editorial changes; draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt has been published, and is ready for WG chair final review and then IESG review draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt: Accept with editorial changes; draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt has been published, and is ready for WG chair final review and then IESG review _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 12:16:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02186; Tue, 4 Mar 2003 12:16:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HR5p23812; Tue, 4 Mar 2003 12:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HQnp23745 for ; Tue, 4 Mar 2003 12:26:49 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02148 for ; Tue, 4 Mar 2003 12:15:44 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24HHk57021295; Tue, 4 Mar 2003 09:17:47 -0800 (PST) Date: Tue, 4 Mar 2003 12:17:46 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org, , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Results of WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt: Accept with editorial changes, as summarized in previous e-mail http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01827.html; draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt has been submitted for publication and will be ready for IESG review (there is a minor issue remaining concerning the naming of the "DNS resolver" option) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 4 22:40:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20705; Tue, 4 Mar 2003 22:40:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h253pD507740; Tue, 4 Mar 2003 22:51:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h253ne507685 for ; Tue, 4 Mar 2003 22:49:40 -0500 Received: from SCBH02.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20668 for ; Tue, 4 Mar 2003 22:38:22 -0500 (EST) Received: by SCBH02.terayon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 19:39:45 -0800 Message-ID: From: "Hazon, Dan" To: "'dhcwg@ietf.org'" Date: Tue, 4 Mar 2003 19:39:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Lease Query to multiple servers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This comment is regarding the document There at the end of section 6.2 it says: "The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, and in the absence of information concerning which DHCP server might possess authoritative information concerning the IP address, it SHOULD be sent to all DHCP servers configured for the associated relay agent (if any are known)." Yet the document does not suggest what should a BOOTP Relay Agent do with multiple answers, (possibly contradicting) from different servers. My view is the following: Active lease should be considered first if there is no active lease then a reservation may be used. If more then one DHCP server claims it has an active lease it should be logged as an error condition, none of the replies should be used, and the information should be logged to avoid frequent query of the same. I think a short paragraph clearing this scenario is required the same way the scenario of no response is discussed in section 6.6 Does it make sense? Dan _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 5 06:31:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26336; Wed, 5 Mar 2003 06:31:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BgI517247; Wed, 5 Mar 2003 06:42:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bdg516853 for ; Wed, 5 Mar 2003 06:39:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25438; Wed, 5 Mar 2003 06:28:14 -0500 (EST) Message-Id: <200303051128.GAA25438@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Mar 2003 06:28:13 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : DNS Configuration Options for DHCPv6 Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt Pages : 7 Date : 2003-3-4 This document describes DHCPv6 options for passing a list of available DNS Servers and a domain search list to a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.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: <2003-3-4173744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173744.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 5 18:45:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06509; Wed, 5 Mar 2003 18:45:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25NuIO02788; Wed, 5 Mar 2003 18:56:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Nq8O02666 for ; Wed, 5 Mar 2003 18:52:08 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06402; Wed, 5 Mar 2003 18:40:51 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h25NgtZ14949; Wed, 5 Mar 2003 15:42:55 -0800 (PST) Message-Id: <200303052342.h25NgtZ14949@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Mar 2003 15:42:55 -0800 Subject: [dhcwg] RFC 3495 on Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3495 Title: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration Author(s): B. Beser, P. Duffy, Ed. Status: Standards Track Date: March 2003 Mailbox: burcak@juniper.net, paduffy@cisco.com Pages: 13 Characters: 26817 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-packetcable-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3495.txt This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. 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.echo 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: <030305154108.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3495 --OtherAccess Content-Type: Message/External-body; name="rfc3495.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030305154108.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 02:30:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26732; Thu, 6 Mar 2003 02:30:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267fQO09458; Thu, 6 Mar 2003 02:41:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h266Z4O26761 for ; Thu, 6 Mar 2003 01:35:04 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14510 for ; Thu, 6 Mar 2003 01:23:36 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B710715210; Thu, 6 Mar 2003 15:26:22 +0900 (JST) Date: Thu, 06 Mar 2003 15:25:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: PD lifetime issues again (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Mar__6_15:25:58_2003-1" X-Dispatcher: imput version 20000228(IM140) Lines: 301 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Multipart_Thu_Mar__6_15:25:58_2003-1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sorry for not responding sooner. =46rom this message, I'll separate the thread for each particular issue. >>>>> On Fri, 28 Feb 2003 00:46:37 +0000,=20 >>>>> Ole Troan said: >> 1. Issues about the preferred and valid lifetimes were not fully >> addressed. I've not seen consensus on this in the dhc-wg ML. >> Please re-check the thread entitled "PD lifetimes" that started on >> Thu, 23 Jan 2003 19:18:57 +0900. > what specifically are you referring to here? in my opinion we reached > consensus that: > - both preferred and valid lifetimes are needed > - prefixes or addresses derived from the prefix MUST not be used > beyond the valid lifetime These two are okay. > - adding P and V bits to specify if a prefix advertised in an RA > should use a fixed lifetime or a real time lifetime, is not needed > as it does not seem to add value or solve any specific problem. I'm not yet fully convinced on this, particularly about the P bit. The motivation of having the preferred lifetime should be to allow the delegating router to control smooth renumbering. In a renumbering phase, the preferred (and valid) lifetime in RA at a downstream link should be decreasing in real time. But it is not clear to me how the preferred lifetime in RA is decreasing. The PD draft just says: A requesting router MAY use the preferred lifetime specified in the IA_PD Prefix option. (Section 11.1 of prefix-delegation-02) What does "use" mean here? If it means the requesting router copies the PD pltime to the RA pltime, the latter won't decrease. If this has the same meaning as that for the valid lifetime: the requesting router MUST set the valid lifetime in those advertisements to be no later than the valid lifetime specified in the IA_PD Prefix option. (just before the sentence cited above) why not just use the same phrase? I also requested that the default value of the valid lifetime in a PD prefix option be larger than AdvValidLifetime (see the "summary" part of the message). At least I've not seen a "consensus" to reject the request. Erik rather seemed to share my motivation according to the discussion after the attached message below. Furthermore, I still have a concern about the difference between the role of prefix pltime and that of address pltime (I have repeatedly tried to point it out, but perhaps I was not clear enough). The former is a kind of an optional parameter, while the latter is a mandatory one: A requesting router MAY use the preferred lifetime specified in the IA_PD Prefix option. (Section 11.1 of prefix-delegation-02) In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. (Section 22.6. of dhc-dhcpv6-28) Note the former uses a MAY but the latter uses a MUST. Despite the difference on the requirement level, the PD draft has (almost) exactly the same recommendation about the relationship between T1/T2 and pltime as that of the DHCPv6 draft: Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the prefixes in the IA_PD, respectively. (Section 8 of prefix-delegation-02) Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA, respectively. (Section 22.4 of dhc-dhcpv6-28) The recommendation of DHCPv6 seems reasonable, since the client MUST use the preferred lifetime in the IA. In the PD case, however, the requesting router (i.e. the client) MAY "NOT" use the preferred lifetimes in the IA_PD, which makes the recommendation less reasonable. Now I have a concrete proposal. - add a special value for the PD preferred lifetime which means the requesting router can choose the RA preferred lifetime. 0 would be a reasonable value for this. - change the default value of the PD preferred lifetime to the special value. - change the requesting router behavior on the received preferred lifetime to: (if the preferred lifetime in IA_PD is not the special value) the requesting router MUST set the preferred lifetime in those advertisements to be no later than the preferred lifetime specified in the IA_PD Prefix option. - change the recommendation on the T1/T2 values so that they are based on the valid lifetimes, e.g.: Recommended values for T1 and T2 are .5 and .8 times the shortest valid lifetime of the prefixes in the IA_PD, respectively. - (assuming the change on the recommendation) choose the default value of the PD valid lifetime so that the RA valid lifetime won't decrease as long as Renew/Reply exchanges succeed. 5 times the AdvValidLifetime would be a good candidate. - (optional) it may also make the intention clearer if we could change the field name of PD valid and preferred lifetimes to, e.g., "lease-time" and "adv-preferred-lifetime", respectively. With this proposal, the typical (default) operation will be like this: (assuming 0 as the "special value" for the PD preferred lifetime) - the delegating router suggests a following parameters for each prefix: AdvValidLifetime * 5 (150 days) as the valid lifetime 0 as the preferred lifetime and T1/T2 be 75/120 days. - before T2 expires, the requesting router can use any value for RA=20 valid lifetime not larger than 30 days (AdvValidLifetime). In particular, it can use the constant value of AdvValidLifetime. - similarly, the requesting router can use any value for RA preferred lifetime not larger than RA valid lifetime until T2 expires. In particular, it can use the constant value of AdvPreferredLifetime. When the delegating side wants to initiate a renumbering, the delegating router will specify a positive (but finite) value as PD preferred lifetime. Then the succeeding RA preferred lifetime will decrement in real time. I strongly believe the proposed change makes the specification clearer in terms of the intended usage of PD (comparing to that of address assignment). Also, the proposed change does not require a large change on the actual behavior on the current draft; it just changes the default value of the lifetime field, and introduces a minor change about the relationship between PD lifetimes and RA lifetimes. Thus, I don't think the change affects early implementations much. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Mar__6_15:25:58_2003-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.1.0) for jinmei@localhost (single-drop); Mon, 27 Jan 2003 00:17:14 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0QEAiR88146 for ; Sun, 26 Jan 2003 23:10:44 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id h0QEAiv01832 for ; Sun, 26 Jan 2003 23:10:44 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id XAA01397 for ; Sun, 26 Jan 2003 23:10:44 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.160.215]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id h0QEAhn20051 for ; Sun, 26 Jan 2003 23:10:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA12899; Sun, 26 Jan 2003 23:10:43 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp with ESMTP id XAA20525 for ; Sun, 26 Jan 2003 23:10:42 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb5.toshiba.co.jp with ESMTP id h0QEAf61019259 for ; Sun, 26 Jan 2003 23:10:41 +0900 (JST) Received: by orange.kame.net (Postfix) id AE26D7151; Sun, 26 Jan 2003 23:10:41 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [203.178.137.85]) by orange.kame.net (Postfix) with ESMTP id 4E1997144 for ; Sun, 26 Jan 2003 23:10:41 +0900 (JST) Received: from www1.ietf.org (ietf.org [132.151.1.19]) by sh.wide.ad.jp (8.11.6+3.4W/8.11.0/smtpfeed 1.18) with ESMTP id h0QEAdi16036; Sun, 26 Jan 2003 23:10:39 +0900 (JST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QEJXJ04833; Sun, 26 Jan 2003 09:19:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q9VHJ25031 for ; Sun, 26 Jan 2003 04:31:17 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15452 for ; Sun, 26 Jan 2003 04:10:51 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q9EHR86987; Sun, 26 Jan 2003 18:14:17 +0900 (JST) Date: Sun, 26 Jan 2003 18:14:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: References: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-UIDL: ~jJ!!*:o"!W2*#!K&o"! X-Spam-Status: No, hits=-9.6 required=5.0 tests=AWL,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.41 X-Spam-Level: >>>>> On Sat, 25 Jan 2003 06:46:26 +0100 (CET), >>>>> Erik Nordmark said: > Presumably the PD draft could do this as well by having a bit (or two) > indicating wheter the lifetime(s) should decrement in real time or be > constant. > Would that make sense? Yes, *if we want to allow the delegating router to have the ability to control the downstream valid and preferred lifetimes*. Actually, RFC 2894 (Router Renumbering for IPv6) has a similar notation: V A 1-bit flag indicating that the valid lifetime of the New Prefix MUST be effectively decremented in real time. P A 1-bit flag indicating that the preferred lifetime of the New Prefix MUST be effectively decremented in real time. (Section 3.2.1.2) The current PD draft implicitly assumes the (not-yet-introduced) additional flags are on, while these bits are off in the current typical cases. Before going that further, however, I still think it is overkilling for the delegating router to have the ability to control the downstream lifetimes. IMO, the requesting router (and the site's administrator) should be responsible for such parameters, with one trivial constraint: the site lifetimes must not be smaller than the lifetimes of each downstream link. In summary, I first would like to make a consensus if we need to allow the requesting router to have the ability to control the downstream lifetimes. As I said above, I'm negative on this. If our consensus is to allow the delegating router to have the ability, it's okay. Then, 1. the requesting router should also have the additional bits (like P and V above), 2. (this may be controversial) the lifetimes in router advertisement on each downstream link should be the same as the default of RFC 2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT decreasing in real time), as long as Renew/Reply exchanges succeed, and 3. in any case, the valid lifetime of a prefix delegated by PD must not be smaller than the valid lifetime in router advertisements on any downstream link. Note that, as a consequence of 2 and 3, the default value of the valid lifetime in a PD prefix option must be larger than AdvValidLifetime. 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 --Multipart_Thu_Mar__6_15:25:58_2003-1-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 02:31:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26794; Thu, 6 Mar 2003 02:31:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267fhO09537; Thu, 6 Mar 2003 02:41:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267N9O07698 for ; Thu, 6 Mar 2003 02:23:09 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26054 for ; Thu, 6 Mar 2003 02:11:42 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A311015210; Thu, 6 Mar 2003 16:14:29 +0900 (JST) Date: Thu, 06 Mar 2003 16:14:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 89 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>> Ole Troan said: >> 2. Section 11.1 now specifies the requesting router to use >> Rebind/Reply exchanges to verify an existing binding (instead of >> Renew/Reply exchanges). According to the very recent >> clarifications on the base DHCPv6 spec, however, I'm not sure if >> Rebind is appropriate here; the server should drop the Rebind >> message unless it has an explicit knowledge about the validity or >> invalidity of the prefix, which should not be the case (e.g.) when >> the upstream link flaps. > Rebind now behaves just like Confirm. if by link flap you mean change > of link to another delegating router, the delegating router can reply > to a Rebind even without a binding if it knows through explicit > configuration that the prefixes in the IA_PD is not valid for the link. Are you referring to the following part of draft-ietf-dhc-dhcpv6-interop-00.txt? 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and 18.2.4 Resolution: Leave the sentence in section 18.2.3 unchanged. Replace the sentence in section 18.2.4 with the following text: If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message it silently discards the Rebind message. The problem here is that this is a MAY requirement and that "explicit configuration information" is ambiguous. Since this is a MAY, the delegating router (i.e. server) MAY NOT send a Reply message, which will cause a bad effect (that the invalid prefix is going to be used). For the case of address assignment, this should be a minor issue, because this situation only happens when none of the events to issue a Confirm happen but the upstream router has somehow been swapped. For the PD case, however, we don't have Confirm/Reply exchanges. So the requirement level should be stronger enough. The same argument should apply to the ambiguous of the wording "explicit configuration information". In my understanding, the author intentionally uses an ambiguous term because this is a very minor case and there can be a (unidentified) trick to build the explicit information, e.g., a background communication between a primary server and a secondary one. Again, for the PD case, this is more likely to happen, so we need to be specific enough. Thus, I would suggest to add the following text (or something like this) to the delegating router behavior: If the delegating router cannot find a requesting router entry for the IA_PD and the delegating router determines that the prefixes in the IA_PD are not appropriate for the requesting router according to the delegating router's explicit configuration information, the delegating router SHOULD send a Reply message to the requesting router containing the requesting router's IA_PD, with the lifetimes for the prefixes in the IA_PD set to zero. This Reply constitutes an explicit notification to the requesting router that the prefixes in the IA_PD are no longer valid. The explicit configuration information of the delegating router contains the fact that the proposed prefixes from the requesting router is not covered by a prefix for the organization of the delegating router. In summary, I propose to change MAY to SHOULD and to add a concrete example of "explicit configuration information." It would also be helpful to describe how the requesting should react to this event. 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-admin@ietf.org Thu Mar 6 02:32:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26898; Thu, 6 Mar 2003 02:32:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267hMO09662; Thu, 6 Mar 2003 02:43:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267R6O07828 for ; Thu, 6 Mar 2003 02:27:06 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26427 for ; Thu, 6 Mar 2003 02:15:40 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AB8AA15210; Thu, 6 Mar 2003 16:18:27 +0900 (JST) Date: Thu, 06 Mar 2003 16:18:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: NoPrefixAvail against Solicit (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>> Ole Troan said: >> 3. Section 10.2 contains the following sentence (newly added in the >> latest revision): >> >> If the delegating router cannot delegate any prefixes to an IA_PD in >> the message from the requesting router, the delegating router MUST >> include the IA_PD in the Reply message with no prefixes in the IA_PD >> and a Status Code option in the IA_PD containing status code >> NoPrefixAvail. >> >> I guess the "Reply" should be "Advertisement" here, because this >> section is talking about "Delegating Router Solicitation." I also >> guess the sentence was added in response to a question of mine in >> the ML. If so, a similar clarification should be introduced to >> Section 11.2 as well. Additionally, the corresponding client >> behaviors should also be documented. > yes, well spotted. After re-reading the draft, I now believe this part is just invalid in Section 10.2 and should be moved to somewhere in Section 11.2. In fact, NoPrefixAvail in Advertise against Solicit is already documented in the last paragraph of Section 10.2 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-admin@ietf.org Thu Mar 6 02:47:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27235; Thu, 6 Mar 2003 02:47:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267wJO10363; Thu, 6 Mar 2003 02:58:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267j9O09772 for ; Thu, 6 Mar 2003 02:45:09 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26960 for ; Thu, 6 Mar 2003 02:33:43 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7DC8C15210; Thu, 6 Mar 2003 16:36:30 +0900 (JST) Date: Thu, 06 Mar 2003 16:36:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: DHCPv6 clarification draft and PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 48 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>> Ole Troan said: >> 4. The PD draft should reflect some parts of >> draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections >> 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. > I have made the changes where appropriate, i.e where we already have > cut and pasted text from the DHCPv6 base specification. I don't think it's enough. For example, Section 8 of prefix-delegation-02 is almost the exact copy of Section 22.4 of dhcpv6-28, with s/IA_NA/IA_PD/g and s/address/prefix/g. Since Section 2 of dhcpv6-interop-00 proposes to "add" paragraphs to Section 22.4 of dhcpv6-28, corresponding paragraphs should be added to Section 8 of prefix-delegation. I've not gone thorough the entire issues of the interop draft, but I'm quite sure that there still exist similar cases. (If you are not convinced, I'll try to make a complete list.) >> We may be able to omit some of them as trivial clarifications, but >> we should reflect some other part of them because the base DHCPv6 >> spec (and thus the clarifications for it) is too specific to >> address assignment. In some cases, implementors can use analogy of >> the base spec to implement the PD draft, but we should basically >> provide comprehensive information in the PD draft itself to ensure >> better interoperability. (As some people, including me, have >> repeatedly pointed out, the best approach would be to make the base >> spec generic so that each stateful method can just refer to the >> base spec. Since we could not make it due to the "it's too late" >> reason, we should be responsible to implementors for providing >> detailed information within the PD specification). > the PD specification is not meant to be complete and needs to be read > in conjunction with the base DHCP specification. I know (and agree), but I'm saying the PD specification should be clear wherever a difference between address assignment and prefix delegation exist. We should be rather redundant than leave the difference ambiguous. At least please reconsider each issue in the interop draft and merge necessary changes from 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-admin@ietf.org Thu Mar 6 06:27:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02964; Thu, 6 Mar 2003 06:27:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BcSO26422; Thu, 6 Mar 2003 06:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BbKO26141 for ; Thu, 6 Mar 2003 06:37:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02504; Thu, 6 Mar 2003 06:25:50 -0500 (EST) Message-Id: <200303061125.GAA02504@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 06:25:50 -0500 Subject: [dhcwg] I-D ACTION:draft-gupta-dhcp-auth-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Flexible Authentication for DHCP Messages Author(s) : V. Gupta Filename : draft-gupta-dhcp-auth-01.txt Pages : 17 Date : 2003-3-5 This memo proposes a new protocol for DHCP authentication within the general framework outlined in RFC 3118 [4]. This protocol uses public-key cryptography, in the form of digital signatures, for authentication. This simplifies key management and supports mutual authentication between clients and servers belonging to different administrative domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-dhcp-auth-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gupta-dhcp-auth-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-gupta-dhcp-auth-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: <2003-3-5140458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-dhcp-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-gupta-dhcp-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140458.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 06:28:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03186; Thu, 6 Mar 2003 06:28:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BdIO26507; Thu, 6 Mar 2003 06:39:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BaLO25529 for ; Thu, 6 Mar 2003 06:36:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02315; Thu, 6 Mar 2003 06:24:51 -0500 (EST) Message-Id: <200303061124.GAA02315@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 06:24:51 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-implementation-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Implementation Issues with RFC 2131, 'Dynamic Host Configuration Protocol' Author(s) : R. Hibbs Filename : draft-ietf-dhc-implementation-00.txt Pages : 19 Date : 2003-3-5 This memo identifies implementation issues with RFC 2131, 'Dynamic Host Configuration Protocol,' reported by a number of implementors, assesses the severity of the problem, then proposes changes to RFC 2131 intended to overcome the issues. This is intended for use as the basis for discussion of RFC 2131 before it is proposed for Internet Standard status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-implementation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-implementation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5140241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-implementation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-implementation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140242.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 06:28:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03226; Thu, 6 Mar 2003 06:28:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BdJO26523; Thu, 6 Mar 2003 06:39:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BaPO25533 for ; Thu, 6 Mar 2003 06:36:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02333; Thu, 6 Mar 2003 06:24:56 -0500 (EST) Message-Id: <200303061124.GAA02333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 06:24:55 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : KDC Server Address Sub-option Author(s) : K. Luehrs, R. Woundy, J. Bevilacqua Filename : draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt Pages : 4 Date : 2003-3-5 This document defines a new sub-option for the CableLabs Client Configuration (CCC) DHCP option code for conveying the network address of the Key Distribution Center (KDC) server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-suboptions-kdc-serveraddress-03.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-suboptions-kdc-serveraddress-03.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: <2003-3-5140252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140252.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 06:28:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03231; Thu, 6 Mar 2003 06:28:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BdLO26539; Thu, 6 Mar 2003 06:39:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BaUO25538 for ; Thu, 6 Mar 2003 06:36:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02352; Thu, 6 Mar 2003 06:25:00 -0500 (EST) Message-Id: <200303061125.GAA02352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 06:25:00 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-pktc-kerb-tckt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Security Ticket Control Sub-option for the CableLabs Client Configuration Option Author(s) : P. Duffy Filename : draft-ietf-dhc-pktc-kerb-tckt-01.txt Pages : 6 Date : 2003-3-5 This document defines a new sub-option for the CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate locally persisted Kerberos tickets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-pktc-kerb-tckt-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-pktc-kerb-tckt-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: <2003-3-5140302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pktc-kerb-tckt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140302.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 06:52:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06041; Thu, 6 Mar 2003 06:52:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26C3QO28711; Thu, 6 Mar 2003 07:03:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26C2gO28650 for ; Thu, 6 Mar 2003 07:02:42 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05867; Thu, 6 Mar 2003 06:51:11 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26BrDkD020982; Thu, 6 Mar 2003 06:53:13 -0500 (EST) Received: from rdroms-w2k.cisco.com (ams-clip-vpn-dhcp130.cisco.com [10.61.64.130]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA15450; Thu, 6 Mar 2003 06:53:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030306034236.037fa310@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Mar 2003 03:43:35 -0500 To: agenda@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agend for dhc WG at IETF 56 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG agenda - IETF 56 (Last revised 3/6/03 2:03) ------------------------------ Administrivia; agenda bashing; WG progress report Ralph Droms 5 minutes Review of new charter; request for milestones Ralph Droms 10 minutes DHCP security review team report Barr Hibbs 10 minutes 'Securing DHCP with DNSSEC bourne public keys' Ted Lemon 15 minutes Authentication of relay agent options John Schnizlein 10 minutes DHCP server MIB Barr Hibbs 10 minutes Option code recovery Ralph Droms 5 minutes Option code extensions Bernie Volz 10 minutes Review of DHCP RFCs Barr Hibbs 10 minutes Failover protocol Kim Kinnear 10 minutes Lease query protocol Kim Kinnear 10 minutes DHCPv6 status Ralph Droms 10 minutes DHCPv6 Interoperability test results DHCPv6 options ---------- Total 115 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 08:02:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10974; Thu, 6 Mar 2003 08:02:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DDMO02226; Thu, 6 Mar 2003 08:13:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DCaO02190 for ; Thu, 6 Mar 2003 08:12:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10877; Thu, 6 Mar 2003 08:01:03 -0500 (EST) Message-Id: <200303061301.IAA10877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 08:01:03 -0500 Subject: [dhcwg] I-D ACTION:draft-gupta-dhcp-auth-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Flexible Authentication for DHCP Messages Author(s) : V. Gupta Filename : draft-gupta-dhcp-auth-02.txt Pages : 17 Date : 2003-3-5 This memo proposes a new protocol for DHCP authentication within the general framework outlined in RFC 3118 [4]. This protocol uses public-key cryptography, in the form of digital signatures, for authentication. This simplifies key management and supports mutual authentication between clients and servers belonging to different administrative domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-dhcp-auth-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gupta-dhcp-auth-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-gupta-dhcp-auth-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: <2003-3-6081727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-dhcp-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-gupta-dhcp-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6081727.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 10:14:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19531; Thu, 6 Mar 2003 10:14:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FPKO13019; Thu, 6 Mar 2003 10:25:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FOrO12978 for ; Thu, 6 Mar 2003 10:24:53 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19440 for ; Thu, 6 Mar 2003 10:13:19 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 796D21C00D9D; Thu, 6 Mar 2003 07:15:20 -0800 (PST) Received: from india.hp.com (nt23073.india.hp.com [15.42.230.73]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with ESMTP id UAA29314; Thu, 6 Mar 2003 20:44:33 +0530 (IST) Message-ID: <3E6766E2.5050904@india.hp.com> Date: Thu, 06 Mar 2003 20:48:58 +0530 From: Senthil Kumar B Organization: Hewlett Packard ISO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon Cc: Bud Millwood , "Vasu, Vallabhaneni" , dhcwg@ietf.org Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. References: <6A0683BE-3880-11D7-A2AE-00039367340A@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for your reply. Have you heard of any commerical/operational implementation of DHCP/BOOTP server which replies to a non-standard port. If the server is the replying to a non-standard port, will be there any security issues.? For example, any non root users can write a program which sends continuous request and get all the IP addresses leading to DoS attack. would really appreciate your help. Ted Lemon wrote: >> We respond to the source port the client is using, but allow the >> administrator >> to override this at the server. It seemed like a bad idea to respond >> to a >> fixed port if no communication had been initiated from that port. > > > The RFC is explicit about the port numbers to use when sending > messages. If you send to or from other ports, you are not doing > DHCP. Which is not to say that what you are doing is wrong for the > particular case you're working on, but it isn't what's stated in the > protocol specification. You can't count on being able to > interoperate successfully with conforming devices if you don't use the > port numbers that the standard requires. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 10:48:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21742; Thu, 6 Mar 2003 10:48:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FtGO15728; Thu, 6 Mar 2003 10:55:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FqSO15565 for ; Thu, 6 Mar 2003 10:52:28 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21051 for ; Thu, 6 Mar 2003 10:40:53 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id DE8B61C00CAC for ; Thu, 6 Mar 2003 07:42:55 -0800 (PST) Received: from india.hp.com (nt23073.india.hp.com [15.42.230.73]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with ESMTP id VAA01001 for ; Thu, 6 Mar 2003 21:12:13 +0530 (IST) Message-ID: <3E676D5E.8060009@india.hp.com> Date: Thu, 06 Mar 2003 21:16:38 +0530 From: Senthil Kumar B Organization: Hewlett Packard ISO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP Security threat. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit RFC 2131 doesn't mandate the DHCP server to check whether a request is from a standard client port(68). If this is being the case, a normal user can just write a program and send continuous DHCP request(series of DHCPDISCOVER, DHCPREQUEST) without bothering the reply from the server which eventually causes the IP address pool to exhaust. It's a DoS. What is the mechanism used to prevent these kind of DoS attacks? I understand "Authentication to DHCP messages" RFC Shares key information between reliable clients which the administrator will cofigure. But again, one out of the reliable clients can do this job and exhaust the pool which is simply a DoS. Please advise how should it be handled. Thanks, Senthil K Bala. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 11:12:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23744; Thu, 6 Mar 2003 11:12:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GMrO18979; Thu, 6 Mar 2003 11:22:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GJhO18519 for ; Thu, 6 Mar 2003 11:19:43 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23274 for ; Thu, 6 Mar 2003 11:08:07 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.8/8.12.8) with ESMTP id h26GA8sB022782; Thu, 6 Mar 2003 10:10:08 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.8/8.12.8) with ESMTP id h26GA7j7017025; Thu, 6 Mar 2003 10:10:07 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 10:10:07 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Senthil Kumar B'" , dhcwg Subject: RE: [dhcwg] DHCP Security threat. Date: Thu, 6 Mar 2003 10:08:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E3FA.9D2D6FC8" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2E3FA.9D2D6FC8 Content-Type: text/plain; charset="iso-8859-1" Senthil: Many stacks have no security and if a hacker is going to do this, they can also likely get by any security measures that are in place to require "privileges" to use a low port number (<1024). Also, the act of sending the packets and having the server have to process them to discard those packets from improper ports can result in a DoS attack (since the server and network will be much slower). - Bernie -----Original Message----- From: Senthil Kumar B [mailto:ksenthil@india.hp.com] Sent: Thursday, March 06, 2003 10:47 AM To: dhcwg Subject: [dhcwg] DHCP Security threat. RFC 2131 doesn't mandate the DHCP server to check whether a request is from a standard client port(68). If this is being the case, a normal user can just write a program and send continuous DHCP request(series of DHCPDISCOVER, DHCPREQUEST) without bothering the reply from the server which eventually causes the IP address pool to exhaust. It's a DoS. What is the mechanism used to prevent these kind of DoS attacks? I understand "Authentication to DHCP messages" RFC Shares key information between reliable clients which the administrator will cofigure. But again, one out of the reliable clients can do this job and exhaust the pool which is simply a DoS. Please advise how should it be handled. Thanks, Senthil K Bala. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2E3FA.9D2D6FC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP Security threat.

Senthil:

Many stacks have no security and if a hacker is going = to do this, they can also likely get by any security measures that are = in place to require "privileges" to use a low port number = (<1024). Also, the act of sending the packets and having the server = have to process them to discard those packets from improper ports can = result in a DoS attack (since the server and network will be much = slower).

- Bernie

-----Original Message-----
From: Senthil Kumar B [mailto:ksenthil@india.hp.com]<= /FONT>
Sent: Thursday, March 06, 2003 10:47 AM
To: dhcwg
Subject: [dhcwg] DHCP Security threat.


RFC 2131 doesn't mandate the DHCP server to check = whether a request is
from a standard client port(68).  If this is = being the case, a normal
user can just write a program and send continuous = DHCP request(series of
DHCPDISCOVER, DHCPREQUEST) without bothering the = reply from the server
which eventually causes the IP address pool to = exhaust. It's a DoS.

What is the mechanism used to prevent these kind of = DoS attacks?

I understand "Authentication to DHCP = messages" RFC Shares key
information between reliable clients which the = administrator will
cofigure. But again, one out of the reliable clients = can do this job and
exhaust the pool which is simply a DoS.

Please advise how should it be handled.

Thanks,
Senthil K Bala.

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

------_=_NextPart_001_01C2E3FA.9D2D6FC8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 6 12:00:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28446; Thu, 6 Mar 2003 12:00:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HAnO23720; Thu, 6 Mar 2003 12:10:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Gq8O21800 for ; Thu, 6 Mar 2003 11:52:08 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25953 for ; Thu, 6 Mar 2003 11:40:31 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id E3A691B2082; Thu, 6 Mar 2003 10:38:22 -0600 (CST) Date: Thu, 6 Mar 2003 10:42:30 -0600 Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Bud Millwood , "Vasu, Vallabhaneni" , dhcwg@ietf.org To: Senthil Kumar B From: Ted Lemon In-Reply-To: <3E6766E2.5050904@india.hp.com> Message-Id: <9F449BCC-4FF2-11D7-93FC-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If the server is the replying to a non-standard port, will be there > any security issues.? > > For example, any non root users can write a program which sends > continuous request and get all the IP addresses leading to DoS attack. The distinction between root and non-root is pretty elusive in this day and age. I wouldn't worry about it - if someone wants to do a DHCP-based DoS attack, they will be able to do it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 01:32:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01540; Fri, 7 Mar 2003 01:32:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h276h5O10316; Fri, 7 Mar 2003 01:43:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h276fBO10218 for ; Fri, 7 Mar 2003 01:41:11 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01482 for ; Fri, 7 Mar 2003 01:29:16 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id A4DEC1C01440; Thu, 6 Mar 2003 22:31:19 -0800 (PST) Received: from india.hp.com (nt23073.india.hp.com [15.42.230.73]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with ESMTP id MAA20970; Fri, 7 Mar 2003 12:00:41 +0530 (IST) Message-ID: <3E683D9B.4080005@india.hp.com> Date: Fri, 07 Mar 2003 12:05:07 +0530 From: Senthil Kumar B Organization: Hewlett Packard ISO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bud Millwood Cc: "Vasu, Vallabhaneni" , dhcwg@ietf.org Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. References: <3E3F8B23.CF70A9A1@india.hp.com> <3E3FC2AD.6F75FC1C@austin.ibm.com> <200302041606.27750.budm@weird-solutions.com> Content-Type: multipart/alternative; boundary="------------020500010502020203000703" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --------------020500010502020203000703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Does any commercial versions of DHCP server supports resource limiting (as you mentioned in your mail) using option 82 (Relay Agent Information Option-RFC 3046). Bud Millwood wrote: >On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni wrote: > > > >>This problem can happen even if the client uses the standard ports. All you >>need to do is write c code to generate different client id's (MAC or option >>61). This issue is being handled in RFC 3118. >> >> > >We respond to the source port the client is using, but allow the administrator >to override this at the server. It seemed like a bad idea to respond to a >fixed port if no communication had been initiated from that port. > >The best way to handle spoofing today, to my knowledge, is to use the trusted >values found in option 82 for identifying the client. If your server supports >resource limiting using option 82, and your relay agents support option 82, >you should be fine. > >Otherwise, some sort of pre-registration works, although that's a bit of a >pain to manage. > >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 > > > --------------020500010502020203000703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Does any commercial versions of DHCP server supports resource limiting (as you mentioned in your mail) using option 82 (Relay Agent Information Option-RFC 3046).

Bud Millwood wrote:
On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni wrote:

  
This problem can happen even if the client uses the standard ports. All you
need to do is write c code to generate different client id's (MAC or option
61). This issue is  being handled in RFC 3118.
    

We respond to the source port the client is using, but allow the administrator 
to override this at the server. It seemed like a bad idea to respond to a 
fixed port if no communication had been initiated from that port.

The best way to handle spoofing today, to my knowledge, is to use the trusted 
values found in option 82 for identifying the client. If your server supports 
resource limiting using option 82, and your relay agents support option 82, 
you should be fine.

Otherwise, some sort of pre-registration works, although that's a bit of a 
pain to manage.

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

--------------020500010502020203000703-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 06:55:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21939; Fri, 7 Mar 2003 06:55:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C6rO15831; Fri, 7 Mar 2003 07:06:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C0sO15456 for ; Fri, 7 Mar 2003 07:00:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20191; Fri, 7 Mar 2003 06:48:55 -0500 (EST) Message-Id: <200303071148.GAA20191@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:48:55 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-host-option-considerations-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Considerations for the use of the Host Name option Author(s) : C. Smith, T. Lemon Filename : draft-ietf-dhc-host-option-considerations-02.txt Pages : 8 Date : 2003-3-6 This document clarifies the use of the DHCP Host Name option. The primary point of this clarification addresses the use of the option by clients to request proxy DNS updates by DHCP servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-option-considerations-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-host-option-considerations-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-host-option-considerations-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: <2003-3-6124151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-host-option-considerations-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-host-option-considerations-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124151.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 06:55:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21969; Fri, 7 Mar 2003 06:55:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C6xO15847; Fri, 7 Mar 2003 07:06:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C0xO15462 for ; Fri, 7 Mar 2003 07:00:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20209; Fri, 7 Mar 2003 06:49:00 -0500 (EST) Message-Id: <200303071149.GAA20209@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:49:00 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-08.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB Author(s) : R. Hibbs, G. Waters Filename : draft-ietf-dhc-server-mib-08.txt Pages : 51 Date : 2003-3-6 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-server-mib-08.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-server-mib-08.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: <2003-3-6124204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124204.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 09:58:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07654; Fri, 7 Mar 2003 09:58:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FACO01605; Fri, 7 Mar 2003 10:10:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F3oO32655 for ; Fri, 7 Mar 2003 10:03:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06759; Fri, 7 Mar 2003 09:51:46 -0500 (EST) Message-Id: <200303071451.JAA06759@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 09:51:45 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Pages : 20 Date : 2003-3-6 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.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: <2003-3-6172230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6172230.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 10:01:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07837; Fri, 7 Mar 2003 10:01:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FCVO01796; Fri, 7 Mar 2003 10:12:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F45O32692 for ; Fri, 7 Mar 2003 10:04:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06828; Fri, 7 Mar 2003 09:52:01 -0500 (EST) Message-Id: <200303071452.JAA06828@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 09:52:00 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 Failover Protocol Author(s) : R. Droms, K. Kinnear et. al. Filename : draft-ietf-dhc-failover-12.txt Pages : 133 Date : 2003-3-6 DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide such synchronization between two servers. One server is designated the 'primary' server, the other is the 'secondary' server. This document also describes a way to integrate the failover protocol with the DHCP load balancing approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-failover-12.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-failover-12.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: <2003-3-6173128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-failover-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6173128.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 11:09:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12735; Fri, 7 Mar 2003 11:09:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GKOO08506; Fri, 7 Mar 2003 11:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GJkO08401 for ; Fri, 7 Mar 2003 11:19:46 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12700 for ; Fri, 7 Mar 2003 11:07:41 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18rKCX-0007OH-00; Fri, 07 Mar 2003 07:56:01 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 08:02:32 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67AA2@homer.incognito.com.> From: "Kostur, Andre" To: "'Senthil Kumar B'" , Bud Millwood Cc: "Vasu, Vallabhaneni" , dhcwg@ietf.org Subject: RE: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. Date: Fri, 7 Mar 2003 08:02:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E4C2.F59ADAB0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2E4C2.F59ADAB0 Content-Type: text/plain; charset="iso-8859-1" Yes, Incognito Software's IP Commander can. -----Original Message----- From: Senthil Kumar B [mailto:ksenthil@india.hp.com] Sent: Thursday, March 06, 2003 10:35 PM To: Bud Millwood Cc: Vasu, Vallabhaneni; dhcwg@ietf.org Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. Does any commercial versions of DHCP server supports resource limiting (as you mentioned in your mail) using option 82 (Relay Agent Information Option-RFC 3046). Bud Millwood wrote: On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni wrote: This problem can happen even if the client uses the standard ports. All you need to do is write c code to generate different client id's (MAC or option 61). This issue is being handled in RFC 3118. We respond to the source port the client is using, but allow the administrator to override this at the server. It seemed like a bad idea to respond to a fixed port if no communication had been initiated from that port. The best way to handle spoofing today, to my knowledge, is to use the trusted values found in option 82 for identifying the client. If your server supports resource limiting using option 82, and your relay agents support option 82, you should be fine. Otherwise, some sort of pre-registration works, although that's a bit of a pain to manage. 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 ------_=_NextPart_001_01C2E4C2.F59ADAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Can a DHCPv4 server REPLY to non-standard = port.

Yes, Incognito Software's IP Commander can.

-----Original Message-----
From: Senthil Kumar B [mailto:ksenthil@india.hp.com]<= /FONT>
Sent: Thursday, March 06, 2003 10:35 PM
To: Bud Millwood
Cc: Vasu, Vallabhaneni; dhcwg@ietf.org
Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to = non-standard port.


Does any commercial versions of DHCP server supports = resource limiting (as you mentioned in your mail) using option 82 = (Relay Agent Information Option-RFC 3046).

Bud Millwood wrote:

On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni = wrote:

 
This problem can happen even if the client uses the = standard ports. All you
need to do is write c code to generate different = client id's (MAC or option
61). This issue is  being handled in RFC = 3118.
   

We respond to the source port the client is using, = but allow the administrator
to override this at the server. It seemed like a bad = idea to respond to a
fixed port if no communication had been initiated = from that port.

The best way to handle spoofing today, to my = knowledge, is to use the trusted
values found in option 82 for identifying the = client. If your server supports
resource limiting using option 82, and your relay = agents support option 82,
you should be fine.

Otherwise, some sort of pre-registration works, = although that's a bit of a
pain to manage.

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

 

------_=_NextPart_001_01C2E4C2.F59ADAB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 12:47:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19554; Fri, 7 Mar 2003 12:47:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HwMO19606; Fri, 7 Mar 2003 12:58:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HviO19555 for ; Fri, 7 Mar 2003 12:57:44 -0500 Received: from igor.alcpress.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19439 for ; Fri, 7 Mar 2003 12:45:36 -0500 (EST) Received: from db.panug.org (db.panug.org [208.151.249.203]) by igor.alcpress.com (Postfix) with ESMTP id 4EEB05585F for ; Fri, 7 Mar 2003 09:47:39 -0800 (PST) From: Ed Sawicki To: dhcwg@ietf.org Content-Type: text/plain Organization: ALC Message-Id: <1047059258.24520.652.camel@red> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 09:47:39 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Revision of DHCPv6 DNS configuration options Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I just joined this list and am reading the archives. I noticed the message from Robert Elz on March 1, regarding the issue of what names to use to describe various DNS machines. I'm an author of a book on DNS and I face the same issue. For most DNS newbies, the DNS world is daunting. It's has many confusing terms. To simplify it for readers in the early chapters of the book, I use the term resolver in the traditional way. However, "DNS Server" is a far too generic term so I avoid it. The term "name server", while a bit better, is still ambiguous. I instead use "authority server" to describe an authoritative, iterative name server. I noticed that this term was used by some in the BIND world and is terse and accurate. That leaves that other critter that, as Robert pointed out, has thus far eluded proper naming. I think "caching name server" and other such terms are not appropriate because they give the impression that this thing is both an authority server and a recursive name lookup thingy. While BIND combines these functions into one program, this has proven to be a security issue and alternatives exist that are not combined. I've decided to call this a "DNS cache" as Robert mentioned and the djbdns crowd uses. I, therefore, endorse the use of "DNS cache". -- Ed Sawicki ALC _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 13:22:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21496; Fri, 7 Mar 2003 13:22:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IYCO23695; Fri, 7 Mar 2003 13:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IXCO23585 for ; Fri, 7 Mar 2003 13:33:12 -0500 Received: from igor.alcpress.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21445 for ; Fri, 7 Mar 2003 13:21:04 -0500 (EST) Received: from db.panug.org (db.panug.org [208.151.249.203]) by igor.alcpress.com (Postfix) with ESMTP id F1D3A5585F for ; Fri, 7 Mar 2003 10:23:06 -0800 (PST) From: Ed Sawicki To: dhcwg@ietf.org Content-Type: text/plain Organization: ALC Message-Id: <1047061386.1896.657.camel@red> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 10:23:06 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP Option 33 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm new here so my apologies if this is covered somewhere that I should be looking. I'm wondering why DHCP Option 33 (Static Route) does not provide for the sending of a subnet mask along with the destination address. -- Ed Sawicki ALC _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 13:52:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22747; Fri, 7 Mar 2003 13:52:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27J3wO26597; Fri, 7 Mar 2003 14:03:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27J2rO26513 for ; Fri, 7 Mar 2003 14:02:53 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22585 for ; Fri, 7 Mar 2003 13:50:44 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 03D121B21AA; Fri, 7 Mar 2003 12:48:27 -0600 (CST) Date: Fri, 7 Mar 2003 12:52:45 -0600 Subject: Re: [dhcwg] DHCP Option 33 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: Ed Sawicki From: Ted Lemon In-Reply-To: <1047061386.1896.657.camel@red> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I'm wondering why DHCP Option 33 (Static Route) does not > provide for the sending of a subnet mask along with the > destination address. > You want the classless static route option, which has its own rfc. The static routes option predates deployment of classless subnetting on the Internet. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 17:23:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09862; Fri, 7 Mar 2003 17:23:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MYWO19649; Fri, 7 Mar 2003 17:34:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MSoO19284 for ; Fri, 7 Mar 2003 17:28:50 -0500 Received: from howler.tri.sbc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09590 for ; Fri, 7 Mar 2003 17:16:38 -0500 (EST) Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.8/8.12.5) with ESMTP id h27MIgTq001340 for ; Fri, 7 Mar 2003 16:18:42 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id h27MIfx19012 for ; Fri, 7 Mar 2003 16:18:41 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id <1DH9WBA4>; Fri, 7 Mar 2003 16:18:41 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322806@trimail2> From: "Chen, Weijing" To: dhcwg Date: Fri, 7 Mar 2003 16:18:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] DHCP interconnected to RADIUS for AAA Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Questions for DHCP experts: 1) Does today's DHCP protocol specification support the client authentication by user@domain and password? If not, is it possible to extend it? 2) Is there any DHCP server implementation of obtaining IP address assignment through RADIUS protocol (i.e. IP address pool managed by RADIUS)? Thanks. -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 19:19:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17866; Fri, 7 Mar 2003 19:19:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280UUO30609; Fri, 7 Mar 2003 19:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280T7O30517 for ; Fri, 7 Mar 2003 19:29:07 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17694 for ; Fri, 7 Mar 2003 19:16:50 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h280IlJD000533; Fri, 7 Mar 2003 17:18:47 -0700 (MST) Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 17:18:39 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 17:17:57 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637B2@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: dhcwg@ietf.org cc: "'Kim Kinnear'" , "Ralph Droms" , "Thomas Narten" , "Woundy, Richard" Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Fri, 7 Mar 2003 17:18:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277E9551220596-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I don't know the outcome of this thread, after the flurry of comments in support of the DHCP Lease Query functionality -- which included some useful comments to improve the next draft version. Today, as a fairly large cable service provider, I use DHCP Lease Query between distinct vendors of DHCP servers and DOCSIS CMTS relay agents, where it provides great value -- preventing IP address theft among subscribers. In places where I cannot yet deploy this technology, some legitimate subscribers have to use some ugly workarounds (e.g. continuously pinging the first-hop router) in order to defend their legitimately-assigned DHCP address lease. The Lease Query functionality exists in multiple vendor DHCP server implementations and multiple vendor (CMTS) relay agent implementations. Today, these vendors tend to use the documentation of the Lease Query protocol from the Cisco website. While I believe that Lease Query should be standardized within the DHC WG, I am not sure I would refer to this functionality as "access control". Performing source IP address verification is one small piece of router access control. To see the full ugliness of access control from the DiffServ perspective, see RFC 3289 -- this extent of functionality is way beyond the charter of DHC. I don't think we should extend Lease Query to be a generic DHCP server lookup protocol. For example, if a non-relay agent needs to know the lease database information from a DHCP server, it should query the DHCP Server MIB -- which incidentally I believe now is ready for WG last-call. So perhaps some re-wording of the problem statement, and perhaps some pruning of functionality that has crept into the draft, is in order. I am sorry I did not respond to this thread sooner, but I have been overwhelmed with other IETF discussion threads. DiffServ and DHCP Server MIB come immediately to mind. ;^) -- Rich P.S. I remember the original intent of Lease Query -- since I first pitched the Lease Query idea (aka "Third-Party DHCP") back in April 1998, . In fact, I still have the original slide deck on my laptop. ;^) -----Original Message----- From: Kim Kinnear [mailto:kkinnear@cisco.com] Sent: Wednesday, February 26, 2003 12:37 PM To: dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten; Kim Kinnear Subject: [dhcwg] Leasequery: should it be standardized? Folks, We have come to something of a impasse on the leasequery draft, and I need *your* support if you believe we should continue to pursue this draft. =============================================================== Without considerable support from the DHC WG, we will halt work on the leasequery draft and all attempts to bring this work to standard status. =============================================================== If you believe that there is any value in standardizing the leasequery capability, please at least respond to this list ASAP with your positive support. If you have the time and expertise, please read the rest of this email and see if you can offer cogent arguments as to why this is work that the DHC working group should be pursuing. If we don't standardize the leasequery capability, each vendor of access concentrators and DHCP products that wish to use this approach will then need to work together (possibly in some other forum) to try to get their products to be compatible. Of course, it may well be that we are the only folks who see this as a useful capability, and so that may not be an issue at all. Thanks -- Kim ----------------------- Summary ----------------------- In case you haven't been following the email between Thomas Narten and myself, he has been questioning the problem statement of the leasequery draft. Ralph proposed a new problem statement, but Thomas feels that this whole capability is questionable. You are invited to respond to Thomas' arguments, which I have distilled as follows: 1. Doing anything in the DHC WG like supporting "access control in router type devices" is out of scope for the working group, and doesn't fit its current charter. 2. Access control in router type devices is not well enough understood to be sure that: a) leasequery is the right solution. b) any DHC-based approach is the "right" approach to solve this problem. 3. Until we are sure of 2(a), then we should not proceed with this work (I believe that this statement is implicit in Thomas' comments.) ----------------------- Background --------------------------- Here is Ralph's proposed problem statement: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<-MAC/client-id mappings. One way in which these devices can obtain information about IP<-MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<-MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. Thomas' concerns center on the second paragraph above, and he says: Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. My response to Thomas was: This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. Thanks for your interest in the leasequery capability. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 19:36:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19445; Fri, 7 Mar 2003 19:36:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280mCO00363; Fri, 7 Mar 2003 19:48:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280knO32642 for ; Fri, 7 Mar 2003 19:46:49 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19244 for ; Fri, 7 Mar 2003 19:34:33 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h280abH1018275; Fri, 7 Mar 2003 17:36:37 -0700 (MST) Received: from 147.191.89.201 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 17:36:26 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 17:35:57 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637B3@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Hazon, Dan'" cc: "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Lease Query to multiple servers Date: Fri, 7 Mar 2003 17:36:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277E4801221932-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dan, I agree that it makes sense to specify what happens when the relay agent/access concentrator receives multiple responses to the Lease Query message, and the responses don't agree. In fact, I think that section 6.7 of the draft attempts to address this problem: When using the DHCPLEASEQUERY message in an environment where multi- ple DHCP server may contain authoritative information about the same IP address (such as when failover [FAILOVER] is operating), there could be some difficulty in deciding which results are the most use- ful if two servers respond with DHCPLEASEKNOWN messages to the same query. In this case, the client-last-transaction-time can be used to decide which server has more recent information concerning the IP address returned in the "ciaddr" field. However, I don't agree with the statement below that "If more then one DHCP server claims it has an active lease it should be logged as an error condition, none of the replies should be used..." I believe this action is less-than-ideal when the DHCP server is queried in the middle of a DHCP Failover update. The primary DHCP server presumably has up-to-date lease information, and the secondary DHCP server might have stale information before receiving the BNDUPD message for the lease. This particular situation may persist for some time in Failover's COMMUNICATIONS-INTERRUPTED or PARTNER-DOWN states. In fact, if the primary DHCP server is down, the secondary DHCP server may have the up-to-date lease information. If the relay agent chooses to use none of the Lease Query replies, then temporary Failover-related glitches cause one of two undesirable outcomes: 1. The access concentrators drops traffic with legitimate source IP addresses. 2. The access concentrators can no longer detect and drop traffic with illegitimate source IP addresses. -- Rich -----Original Message----- From: Hazon, Dan [mailto:dan.hazon@terayon.com] Sent: Tuesday, March 04, 2003 10:39 PM To: 'dhcwg@ietf.org' Subject: [dhcwg] Lease Query to multiple servers This comment is regarding the document There at the end of section 6.2 it says: "The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, and in the absence of information concerning which DHCP server might possess authoritative information concerning the IP address, it SHOULD be sent to all DHCP servers configured for the associated relay agent (if any are known)." Yet the document does not suggest what should a BOOTP Relay Agent do with multiple answers, (possibly contradicting) from different servers. My view is the following: Active lease should be considered first if there is no active lease then a reservation may be used. If more then one DHCP server claims it has an active lease it should be logged as an error condition, none of the replies should be used, and the information should be logged to avoid frequent query of the same. I think a short paragraph clearing this scenario is required the same way the scenario of no response is discussed in section 6.6 Does it make sense? Dan _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 7 19:52:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21134; Fri, 7 Mar 2003 19:52:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2814BO01858; Fri, 7 Mar 2003 20:04:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MbqO20815 for ; Fri, 7 Mar 2003 17:37:52 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09999 for ; Fri, 7 Mar 2003 17:25:38 -0500 (EST) Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27MRfSc025870; Fri, 7 Mar 2003 17:27:41 -0500 (EST) Received: from rmesserw2k01 (dhcp-161-44-149-170.cisco.com [161.44.149.170]) by bucket.cisco.com (Mirapoint) with ESMTP id ACS31995; Fri, 7 Mar 2003 17:27:40 -0500 (EST) Reply-To: From: "Randall M. Messer" To: Cc: "Randall M. Messer" Subject: RE [dhcwg] Can a DHCPv4 server REPLY to non-standard port..txt Date: Fri, 7 Mar 2003 17:27:40 -0500 Organization: Networking Technology Group - INSMBU Message-ID: <00c101c2e4f8$c3909510$aa952ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C2_01C2E4CE.DABA8D10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C2E4CE.DABA8D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00C3_01C2E4CE.DABA8D10" ------=_NextPart_001_00C3_01C2E4CE.DABA8D10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cisco's CNS Network Registrar V5.5 and soon-to-be released V6.0 can support resource limiting as noted in this thread. The V5.5 release would use our 'extension point' capability, and the V6.0 release will use an internal server feature called 'expressions' to perform this limiting function. - Randy Messer CNS CNR Product Manager ------=_NextPart_001_00C3_01C2E4CE.DABA8D10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Cisco's CNS Network=20 Registrar V5.5 and soon-to-be released V6.0 can support resource = limiting as=20 noted in this thread.
 
The = V5.5 release=20 would use our 'extension point' capability, and the V6.0 release will = use an=20 internal server feature called 'expressions' to perform this limiting=20 function.
 
- = Randy=20 Messer
CNS = CNR Product=20 Manager
------=_NextPart_001_00C3_01C2E4CE.DABA8D10-- ------=_NextPart_000_00C2_01C2E4CE.DABA8D10 Content-Type: text/plain; name="RE [dhcwg] Can a DHCPv4 server REPLY to non-standard port..txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="RE [dhcwg] Can a DHCPv4 server REPLY to non-standard port..txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: [dhcwg] Can a DHCPv4 server REPLY to non-standard = port.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= [Date Prev][Date = Next][Thread Prev][Thread Next][Date Index][Thread Index]=0A= =0A= =0A= =0A=

RE: [dhcwg] Can a DHCPv4 server REPLY to non-standard port.

=0A=
=0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A= =0A=
Title: RE: [dhcwg] Can a DHCPv4 server REPLY to = non-standard port.
=0A= =0A= =0A= =0A= =0A= =0A=

Yes, Incognito Software's IP Commander can.=0A=

=0A= =0A=

-----Original Message-----=0A=
From: Senthil Kumar B [mailto:ksenthil@india.hp.com]=0A=
Sent: Thursday, March 06, 2003 10:35 PM=0A=
To: Bud Millwood=0A=
Cc: Vasu, Vallabhaneni; dhcwg@ietf.org=0A=
Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to = non-standard port.=0A=

=0A=
=0A= =0A=

Does any commercial versions of DHCP server supports = resource limiting (as you mentioned in your mail) using option 82 (Relay = Agent Information Option-RFC 3046).

=0A= =0A=

Bud Millwood wrote:=0A=

=0A= =0A=

On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni = wrote:=0A=

=0A= =0A=

  =0A=
This problem can happen even if the client uses the = standard ports. All you=0A=
need to do is write c code to generate different = client id's (MAC or option=0A=
61). This issue is  being handled in RFC = 3118.=0A=
    =0A=

=0A= =0A=

We respond to the source port the client is using, but = allow the administrator =0A=
to override this at the server. It seemed like a bad = idea to respond to a =0A=
fixed port if no communication had been initiated = from that port.=0A=

=0A= =0A=

The best way to handle spoofing today, to my = knowledge, is to use the trusted =0A=
values found in option 82 for identifying the client. = If your server supports =0A=
resource limiting using option 82, and your relay = agents support option 82, =0A=
you should be fine.=0A=

=0A= =0A=

Otherwise, some sort of pre-registration works, = although that's a bit of a =0A=
pain to manage.=0A=

=0A= =0A=

Bud Millwood=0A=
Weird Solutions, Inc.=0A=
http://www.weird-solutions.com=0A=
tel: +46 8 758 3700=0A=
fax: +46 8 758 3687=0A=
mailto:budm@weird-solutions.com<= /A>=0A=

=0A= =0A=

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

=0A= =0A=

  =0A=

=0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_00C2_01C2E4CE.DABA8D10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Mar 8 18:21:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04031; Sat, 8 Mar 2003 18:21:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NXSO14253; Sat, 8 Mar 2003 18:33:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NRDO14081 for ; Sat, 8 Mar 2003 18:27:13 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02991 for ; Sat, 8 Mar 2003 18:14:30 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h28NGVEY007944; Sat, 8 Mar 2003 15:16:32 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA29884; Sat, 8 Mar 2003 23:16:31 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) From: Ole Troan Date: Sat, 08 Mar 2003 23:16:31 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 06 Mar 2003 16:14:05 +0900") Message-ID: <7t5el5h5u0g.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jinmei-san, >>> 2. Section 11.1 now specifies the requesting router to use >>> Rebind/Reply exchanges to verify an existing binding (instead of >>> Renew/Reply exchanges). According to the very recent >>> clarifications on the base DHCPv6 spec, however, I'm not sure if >>> Rebind is appropriate here; the server should drop the Rebind >>> message unless it has an explicit knowledge about the validity or >>> invalidity of the prefix, which should not be the case (e.g.) when >>> the upstream link flaps. > >> Rebind now behaves just like Confirm. if by link flap you mean change >> of link to another delegating router, the delegating router can reply >> to a Rebind even without a binding if it knows through explicit >> configuration that the prefixes in the IA_PD is not valid for the link. > > Are you referring to the following part of > draft-ietf-dhc-dhcpv6-interop-00.txt? > > 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and > 18.2.4 > > Resolution: Leave the sentence in section 18.2.3 unchanged. Replace > the sentence in section 18.2.4 with the following text: > > If the server cannot find a client entry for the IA and the > server determines that the addresses in the IA are not > appropriate for the link to which the client's interface is > attached according to the server's explicit configuration > information, the server MAY send a Reply message to the client > containing the client's IA, with the lifetimes for the > addresses in the IA set to zero. This Reply constitutes an > explicit notification to the client that the addresses in the > IA are no longer valid. In this situation, if the server does > not send a Reply message it silently discards the Rebind > message. > > The problem here is that this is a MAY requirement and that "explicit > configuration information" is ambiguous. > > Since this is a MAY, the delegating router (i.e. server) MAY NOT send > a Reply message, which will cause a bad effect (that the invalid > prefix is going to be used). For the case of address assignment, this > should be a minor issue, because this situation only happens when none > of the events to issue a Confirm happen but the upstream router has > somehow been swapped. Rebind is only done for 10 seconds (using Confirms timers), then the client goes back to Solicit state. I don't think we can mandate that a delegating router will know in all cases that a prefix is valid for a link or not. I think we should keep the same text and reasoning as in the base spec. could any of the DHCPv6 base spec guys answer why this is a MAY, as it does delay detection of movement. > For the PD case, however, we don't have Confirm/Reply exchanges. So > the requirement level should be stronger enough. we do. just that we have to use a Rebind/Reply exchange using Confirms timers since we want a binding confirmation, rather than just movement detection. > The same argument should apply to the ambiguous of the wording > "explicit configuration information". In my understanding, the author > intentionally uses an ambiguous term because this is a very minor case > and there can be a (unidentified) trick to build the explicit > information, e.g., a background communication between a primary server > and a secondary one. I don't think "explicit configuration" is ambiguous as such. how a server is configured to know which prefixes are appropriate for a link is implementation dependent. > Again, for the PD case, this is more likely to happen, so we need to > be specific enough. why do you say that? isn't it more likely that a host changes links? what cases do you have in mind? > Thus, I would suggest to add the following text (or something like > this) to the delegating router behavior: > > If the delegating router cannot find a requesting router > entry for the IA_PD and the delegating router determines that > the prefixes in the IA_PD are not appropriate for the > requesting router according to the delegating router's > explicit configuration information, the delegating router > SHOULD send a Reply message to the requesting router > containing the requesting router's IA_PD, with the lifetimes > for the prefixes in the IA_PD set to zero. This Reply > constitutes an explicit notification to the requesting router > that the prefixes in the IA_PD are no longer valid. The > explicit configuration information of the delegating router > contains the fact that the proposed prefixes from the > requesting router is not covered by a prefix for the > organization of the delegating router. > > In summary, I propose to change MAY to SHOULD and to add a concrete > example of "explicit configuration information." > > It would also be helpful to describe how the requesting should react > to this event. requesting router should go to Solicit state. I think this will be made clearer in modified base spec/new PD revision where we'll use NotOnLink rather than lifetimes = 0. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Mar 8 18:30:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05682; Sat, 8 Mar 2003 18:30:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NfwO15379; Sat, 8 Mar 2003 18:41:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NUSO14152 for ; Sat, 8 Mar 2003 18:30:28 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03572 for ; Sat, 8 Mar 2003 18:17:44 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h28NJj0E007751; Sat, 8 Mar 2003 15:19:46 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA29936; Sat, 8 Mar 2003 23:19:45 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: NoPrefixAvail against Solicit (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) From: Ole Troan Date: Sat, 08 Mar 2003 23:19:45 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 06 Mar 2003 16:18:03 +0900") Message-ID: <7t5bs0l5tv2.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jinmei-san, >>> 3. Section 10.2 contains the following sentence (newly added in the >>> latest revision): >>> >>> If the delegating router cannot delegate any prefixes to an IA_PD in >>> the message from the requesting router, the delegating router MUST >>> include the IA_PD in the Reply message with no prefixes in the IA_PD >>> and a Status Code option in the IA_PD containing status code >>> NoPrefixAvail. >>> >>> I guess the "Reply" should be "Advertisement" here, because this >>> section is talking about "Delegating Router Solicitation." I also >>> guess the sentence was added in response to a question of mine in >>> the ML. If so, a similar clarification should be introduced to >>> Section 11.2 as well. Additionally, the corresponding client >>> behaviors should also be documented. > >> yes, well spotted. > > After re-reading the draft, I now believe this part is just invalid in > Section 10.2 and should be moved to somewhere in Section 11.2. In > fact, NoPrefixAvail in Advertise against Solicit is already documented > in the last paragraph of Section 10.2 you are absolutely right, I'll fix. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Mar 8 18:35:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06953; Sat, 8 Mar 2003 18:35:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NlmO15643; Sat, 8 Mar 2003 18:47:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NcRO15229 for ; Sat, 8 Mar 2003 18:38:27 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04726 for ; Sat, 8 Mar 2003 18:25:42 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h28NRh0E010292; Sat, 8 Mar 2003 15:27:44 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA00021; Sat, 8 Mar 2003 23:27:42 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 clarification draft and PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) From: Ole Troan Date: Sat, 08 Mar 2003 23:27:42 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 06 Mar 2003 16:36:06 +0900") Message-ID: <7t58yvp5tht.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jinmei-san, >>>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>>> Ole Troan said: > >>> 4. The PD draft should reflect some parts of >>> draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections >>> 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. > >> I have made the changes where appropriate, i.e where we already have >> cut and pasted text from the DHCPv6 base specification. > > I don't think it's enough. For example, Section 8 of > prefix-delegation-02 is almost the exact copy of Section 22.4 of > dhcpv6-28, with s/IA_NA/IA_PD/g and s/address/prefix/g. > > Since Section 2 of dhcpv6-interop-00 proposes to "add" paragraphs to > Section 22.4 of dhcpv6-28, corresponding paragraphs should be added to > Section 8 of prefix-delegation. > > I've not gone thorough the entire issues of the interop draft, but I'm > quite sure that there still exist similar cases. (If you are not > convinced, I'll try to make a complete list.) > >>> We may be able to omit some of them as trivial clarifications, but >>> we should reflect some other part of them because the base DHCPv6 >>> spec (and thus the clarifications for it) is too specific to >>> address assignment. In some cases, implementors can use analogy of >>> the base spec to implement the PD draft, but we should basically >>> provide comprehensive information in the PD draft itself to ensure >>> better interoperability. (As some people, including me, have >>> repeatedly pointed out, the best approach would be to make the base >>> spec generic so that each stateful method can just refer to the >>> base spec. Since we could not make it due to the "it's too late" >>> reason, we should be responsible to implementors for providing >>> detailed information within the PD specification). > >> the PD specification is not meant to be complete and needs to be read >> in conjunction with the base DHCP specification. > > I know (and agree), but I'm saying the PD specification should be > clear wherever a difference between address assignment and prefix > delegation exist. We should be rather redundant than leave the > difference ambiguous. At least please reconsider each issue in the > interop draft and merge necessary changes from it. agree. revision 3 of the PD draft should have most of the issues from the interop document included. the interoperability testing at Connectathon last week showed that the DHCPv6 base spec and PD specifications cannot be that bad. no protocol problems found. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Mar 9 09:16:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21605; Sun, 9 Mar 2003 09:16:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29ESxO15535; Sun, 9 Mar 2003 09:28:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28KtrO03240 for ; Sat, 8 Mar 2003 15:55:53 -0500 Received: from konishi-polis.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04478 for ; Sat, 8 Mar 2003 15:43:13 -0500 (EST) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 9F037151F11; Sat, 8 Mar 2003 15:45:19 -0500 (EST) To: Paul Duffy Cc: dhcwg@ietf.org, Ken Raeburn Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt References: <4.3.2.7.2.20030226170700.023e6bd8@funnel.cisco.com> From: Sam Hartman Date: Sat, 08 Mar 2003 15:45:19 -0500 In-Reply-To: <4.3.2.7.2.20030226170700.023e6bd8@funnel.cisco.com> (Paul Duffy's message of "Wed, 26 Feb 2003 17:17:13 -0500") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> "Paul" == Paul Duffy writes: Paul> I sense that your main objection to this draft is that it Paul> implies that PacketCable Security is not 100% RFC 1510 Paul> compliant. Will one or two lines clarifying this, along Paul> with a ref to the PacketCable Security spec, suffice? That's my only objection to the existence of the draft yes. AS you point out the IESG has already decided they disagree with me, so this objection should be ignored. Paul> Something along the line of... Paul> "Note that the PacketCable Security Specification differs Paul> from RFC 1510, see [ref] for full technical details of Paul> PacketCable's Kerberos implementation". Looks good. Paul> Agreed. Service authorization is a bogus/incorrect Paul> argument. The text... Paul> "The service provider requires this capability to support Paul> operational functions such as disabling a subscriber's Paul> service, forcing re- establishment of security associations, Paul> or for testing and remote diagnostic of CCDs. " Paul> ...needs to be changed to something like... Paul> "The service provider requires this capability to support Paul> operational functions such as forcing re-establishment of Paul> security associations or for testing and remote diagnostic Paul> of CCDs. " Sounds reasonable. Paul> I share Kens concerns re: forcing all tickets to expire. Paul> Public key ops are expensive and we try to avoid them when Paul> possible (for scaling reasons, avalanche restart conditions, Paul> etc.). But you should only need a PKI op for the TGT not for each service ticket. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Mar 9 09:16:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21649; Sun, 9 Mar 2003 09:16:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29ETQO15564; Sun, 9 Mar 2003 09:29:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28MA8O09810 for ; Sat, 8 Mar 2003 17:10:08 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18380 for ; Sat, 8 Mar 2003 16:57:26 -0500 (EST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 768C215210; Sun, 9 Mar 2003 07:00:17 +0900 (JST) Date: Sun, 09 Mar 2003 06:59:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Ole Troan , Ralph Droms , , In-Reply-To: References: <7t5znoiwouv.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 27 Feb 2003 09:35:52 +0200 (EET), >>>>> Pekka Savola said: >> > cover even all the theoretical cases. I'd much rather see a very simple >> > basic version of prefix delegation which can be used to get started. >> > There's no way we could anticipate what will be needed in 3-5 years and we >> > could further define the extensions when they're needed. >> >> well, I have to disagree with you there. keeping PD consistent with >> other DHCP options makes for an easier understanding of how it works >> and for a simpler implementation. the fundamental idea behind using >> DHCP for PD is to re-use the existing DHCP infrastructure including >> option semantics. Distilled into one line: "Prefix Delegation with >> DHCP is done in exactly the same way as address assignment with DHCP is". > I can live with that. > I hear many (two sets of groups) are implementing DHCPv6 either for: > - configuration parameters > - prefix delegation (for the lack of alternatives) > If you don't want address assignment in DHCP, doing it the same way in PD > may seem like a burden. (Just for the record) As an implementor of dhcpv6 (for prefix delegation), I agree with Ole; Keeping PD consistent with other DHCP options is not a burden. It rather made the PD specification clearer and helps implemented it. In fact, the base DHCPv6 spec contains generic notions for stateful resources, such as Identity Associations and binding. The unfortunate thing, however, is that the base spec is still too specific to address allocation than it could be. Again, I, as an implementor, support keeping PD consistent with base DHCPv6 despite the "unfortunate" part. 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-admin@ietf.org Sun Mar 9 11:53:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20311; Sun, 9 Mar 2003 11:53:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29H64O23788; Sun, 9 Mar 2003 12:06:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29H0kO23402 for ; Sun, 9 Mar 2003 12:00:46 -0500 Received: from smtp015.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19221 for ; Sun, 9 Mar 2003 11:47:40 -0500 (EST) Received: from adsl-64-170-118-66.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.66 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Mar 2003 16:49:47 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Cc: "Chen, Weijing" Subject: RE: [dhcwg] DHCP interconnected to RADIUS for AAA Date: Sun, 9 Mar 2003 08:50:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322806@trimail2> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Chen, Weijing > Sent: Friday, March 07, 2003 14:19 > > Questions for DHCP experts: > > 1) Does today's DHCP protocol specification support the client > authentication by user@domain and password? If not, is it possible to > extend it? > ...DHCP is defined by RFCs 2131 and 2132 (ignoring BOOTP for this answer) and extended by RFC 3118. RFC 3118 specifies a mechanism for authentication of DHCP clients and servers and defines two protocols for use to do so. Protocol 0 uses a clear-text authenticator (password, if you will), but does not specify how the authenticator could be constructed. It could be the tuple "user@domain" and "password," but that is a very bad idea in actual practice: it exposes both the user identity and their password to interception. It also has the fundamental flaws for large-scale implementations of key distribution and lack of client and server support for RFC 3118. > 2) Is there any DHCP server implementation of obtaining IP address > assignment through RADIUS protocol (i.e. IP address pool managed > by RADIUS)? > ...while I'm aware of some experimental DHCP server implementations that used RADIUS for user authentication--and granted access to a client whose user was RADIUS authenticated--I'm not certain if any of them are now commercially available. RADIUS servers typically use DHCP for IP address assignment corresponding to the dial-in connections they support, not the other way around. The RADIUS server provides user authentication; the DHCP server treats the RADIUS server as a legitimate client, without further authentication. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 10 14:47:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10216; Mon, 10 Mar 2003 14:47:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AK0RO09626; Mon, 10 Mar 2003 15:00:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AJwZO09546 for ; Mon, 10 Mar 2003 14:58:35 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10145 for ; Mon, 10 Mar 2003 14:44:58 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2AJl3sw026084 for ; Mon, 10 Mar 2003 11:47:04 -0800 (PST) Date: Mon, 10 Mar 2003 14:47:03 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "KDC Server Address Sub-option" . The last call will conclude on Monday, 3/24. draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt describes a new sub-option of the CableLabs Client Configuration (CCC) DHCP option, which provides the IP address(es) of one or more Key Distribution Center (KDC) servers. This document is being considered for Proposed Standard as an extension to the CCC option, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 10 15:06:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11141; Mon, 10 Mar 2003 15:06:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKJCO11243; Mon, 10 Mar 2003 15:19:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKD4O10967 for ; Mon, 10 Mar 2003 15:13:04 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10616 for ; Mon, 10 Mar 2003 14:59:26 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18sTSm-0006L4-00 for ; Mon, 10 Mar 2003 12:01:32 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 12:08:32 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67AC6@homer.incognito.com.> From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Clarification proposed for RFC 3046 Date: Mon, 10 Mar 2003 12:08:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E740.D2527E20" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2E740.D2527E20 Content-Type: text/plain; charset="iso-8859-1" OK, to resurrect this discussion, I've consolodated all of the suggestions supplied by Ralph, Ted, Bernie, and myself. Here's the amended proposal: RFC 3046, as currently written, seems to downplay the use of a Client Identifier in distinguishing between DHCP clients. For example, in section 4.0, RFC 3046 states: "Client Identifier Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server." This is a much different statement than what RFC 2131 has to say about using Client Identifiers in distinguishing between DHCP clients: "If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client." Note that 2131 says "MUST" and 3046 says "need not be used". These two seem to be contrary to each other. So I propose the following changes to RFC 3046. In section 4.0: Change the text: DHCP Address Exhaustion In general, the DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client MAC address, client remote ID) The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. to the following: Client Identification The DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client unique identifier, client remote ID) The "client unique identifier" is defined in section 4.2 of RFC 2131. A DHCP server MUST use the rules specified in Section 4.2 of RFC 2131 to determine the client unique identifier. DHCP Address Exhaustion The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single Remote Agent ID, independent of the client unique identifiers. Also in section 4.0: Change the text: Client Identifier Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server. MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. to the following: Client Unique Identifier Spoofing As a client unique identifier (RFC 2131) may easily be spoofed, the use of the Remote Agent ID and client unique identifier by the server to identify a client make spoofing another client's client unique identifier meaningless unless the spoofed client is also at the same remote agent ID. And since we're talking about 3046, there's a typo in section 1.2 (DHCP is shown as DCHP in the second line). The current text: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits; should be changed to: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DHCP reply broadcast onto thousands of access circuits; ------_=_NextPart_001_01C2E740.D2527E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Clarification proposed for RFC 3046

OK, to resurrect this discussion, I've consolodated = all of the suggestions supplied by Ralph, Ted, Bernie, and = myself.  Here's the amended proposal:


RFC 3046, as currently written, seems to downplay the = use of a Client Identifier
in distinguishing between DHCP clients.  For = example, in section 4.0, RFC 3046
states:

   "Client Identifier Spoofing

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

This is a much different statement than what RFC 2131 = has to say about
using Client Identifiers in distinguishing between = DHCP clients:

   "If the client
   supplies a 'client identifier', the = client MUST use the same 'client
   identifier' in all subsequent messages, = and the server MUST use that
   identifier to identify the = client."

Note that 2131 says "MUST" and 3046 says = "need not be used".  These two
seem to be contrary to each other.  So I = propose the following changes
to RFC 3046.

In section 4.0:

Change the text:

   DHCP Address Exhaustion

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

          &nb= sp; (client IP address,  client MAC address,  client remote = ID)

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

to the following:

    Client Identification

       The DHCP server = may be extended to maintain a database
       with the = "triplet" of

          &nb= sp;  (client IP address,  client unique identifier,  = client remote ID)

       The "client = unique identifier" is defined in section 4.2 of RFC 2131.
       A DHCP server = MUST use the rules specified in Section 4.2 of RFC
       2131 to = determine the client unique identifier.

    DHCP Address Exhaustion

       The DHCP server = SHOULD implement policies that restrict the number of
       IP addresses to = be assigned to a single Remote Agent ID, independent of
       the client = unique identifiers.


Also in section 4.0:

Change the text:

   Client Identifier Spoofing

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

   MAC Address Spoofing

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

to the following:

   Client Unique Identifier Spoofing =

      As a client unique = identifier (RFC 2131) may easily be spoofed, the use of
      the Remote Agent ID = and client unique identifier by the server to identify
      a client make = spoofing another client's client unique identifier meaningless
      unless the spoofed = client is also at the same remote agent ID.




And since we're talking about 3046, there's a typo in = section 1.2 (DHCP is
shown as DCHP in the second line).  The current = text:

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

should be changed to:

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

------_=_NextPart_001_01C2E740.D2527E20-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 10 20:34:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23383; Mon, 10 Mar 2003 20:34:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1koO06035; Mon, 10 Mar 2003 20:46:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1jGO05977 for ; Mon, 10 Mar 2003 20:45:16 -0500 Received: from smtp011.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23328 for ; Mon, 10 Mar 2003 20:31:32 -0500 (EST) Received: from adsl-64-170-118-66.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.66 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Mar 2003 01:33:39 -0000 Reply-To: From: "Barr Hibbs" To: "Shankar Agarwal" Cc: "Dhcwg" , "Chen, Weijing" Subject: RE: [dhcwg] DHCP interconnected to RADIUS for AAA Date: Mon, 10 Mar 2003 17:33:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3E6D2F0A.89A93D07@net.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: shankara@net.com [mailto:shankara@net.com]On Behalf Of Shankar > Agarwal > Sent: Monday, March 10, 2003 16:34 > > Right now we don't have a simple username password authentication > mechanism for DHCP and we have something very complicated which will not > be used in most common deployments. In most of the cases we are happy > with either cleartext user name password or may be MD5 encoded username > password authentication. If we put this within the current DHCP > framework then this will help in replacing the ppp in DSL and cabel > modem world where username password is used to pick up the profile of > the user. > ...you are making an assumption that is not true in the general case: using the tuple "username" and "password" for CLIENT authentication assumes that CLIENT and USER are identically equal. DHCP authentication (per RFC 3118) makes no such claim of equivalence. Can you guarantee that CLIENT and USER are, in fact, identical in your environment? If so, do your policies permit multiple instances of the same user to be "logged-in" simultaneously? If that is permitted by your policies, of what use is it to you? Giving multiple clients the same username and password credentials is equivalent to no protection at all. If your policies do not permit multiple simultaneous instances of a user being logged-in, do you deny all subsequent client configuration attempts until the first has logged off? Also, have you implemented RFC 3118? If so, could you identify the client and server? (vendor name and product name) --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 10 22:01:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25228; Mon, 10 Mar 2003 22:01:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B3EYO11422; Mon, 10 Mar 2003 22:14:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B0jOO02532 for ; Mon, 10 Mar 2003 19:45:24 -0500 Received: from mx01.net.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22213 for ; Mon, 10 Mar 2003 19:31:40 -0500 (EST) Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx01.net.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id h2B0ZAM06117 for ; Mon, 10 Mar 2003 16:35:10 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx01-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h2B0ZA405693 for ; Mon, 10 Mar 2003 16:35:10 -0800 (PST) Received: from net.com ([134.56.24.58]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA1A4A; Mon, 10 Mar 2003 16:34:19 -0800 Message-ID: <3E6D2F0A.89A93D07@net.com> Date: Mon, 10 Mar 2003 16:34:18 -0800 From: Shankar Agarwal Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: rbhibbs@pacbell.net CC: Dhcwg , "Chen, Weijing" Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Right now we don't have a simple username password authentication mechanism for DHCP and we have something very complicated which will not be used in most common deployments. In most of the cases we are happy with either cleartext user name password or may be MD5 encoded username password authentication. If we put this within the current DHCP framework then this will help in replacing the ppp in DSL and cabel modem world where username password is used to pick up the profile of the user. Barr Hibbs wrote: > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > > Chen, Weijing > > Sent: Friday, March 07, 2003 14:19 > > > > Questions for DHCP experts: > > > > 1) Does today's DHCP protocol specification support the client > > authentication by user@domain and password? If not, is it possible to > > extend it? > > > ...DHCP is defined by RFCs 2131 and 2132 (ignoring BOOTP for this answer) > and extended by RFC 3118. RFC 3118 specifies a mechanism for authentication > of DHCP clients and servers and defines two protocols for use to do so. > Protocol 0 uses a clear-text authenticator (password, if you will), but does > not specify how the authenticator could be constructed. It could be the > tuple "user@domain" and "password," but that is a very bad idea in actual > practice: it exposes both the user identity and their password to > interception. It also has the fundamental flaws for large-scale > implementations of key distribution and lack of client and server support > for RFC 3118. > > > 2) Is there any DHCP server implementation of obtaining IP address > > assignment through RADIUS protocol (i.e. IP address pool managed > > by RADIUS)? > > > ...while I'm aware of some experimental DHCP server implementations that > used RADIUS for user authentication--and granted access to a client whose > user was RADIUS authenticated--I'm not certain if any of them are now > commercially available. RADIUS servers typically use DHCP for IP address > assignment corresponding to the dial-in connections they support, not the > other way around. The RADIUS server provides user authentication; the DHCP > server treats the RADIUS server as a legitimate client, without further > authentication. > > --Barr > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 10 23:22:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26517; Mon, 10 Mar 2003 23:22:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B4Z0O15827; Mon, 10 Mar 2003 23:35:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B4X8O15764 for ; Mon, 10 Mar 2003 23:33:08 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26496 for ; Mon, 10 Mar 2003 23:19:20 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2B4LPEY011068; Mon, 10 Mar 2003 20:21:25 -0800 (PST) Received: from cisco.com (stealth-10-34-245-242.cisco.com [10.34.245.242]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEV82580; Mon, 10 Mar 2003 20:16:11 -0800 (PST) Date: Mon, 10 Mar 2003 20:21:24 -0800 Subject: Re: [dhcwg] Leasequery: should it be standardized? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: Kim Kinnear From: Richard Johnson In-Reply-To: <4.3.2.7.2.20030226120723.025d5628@goblet.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ... A little late, but ... Definitely, we should proceed with it. It's currently in use in a number of places. I know our own cable modem code uses it. We've also heard customers describe network designs where it would come in useful. Just my $0.02. /raj On Wednesday, February 26, 2003, at 09:36 AM, Kim Kinnear wrote: > > Folks, > > We have come to something of a impasse on the leasequery draft, > and I need *your* support if you believe we should continue to > pursue this draft. > > =============================================================== > Without considerable support from the DHC WG, we will halt work > on the leasequery draft and all attempts to bring this work to > standard status. > =============================================================== > > If you believe that there is any value in standardizing the > leasequery capability, please at least respond to this list ASAP > with your positive support. > > If you have the time and expertise, please read the rest of this > email and see if you can offer cogent arguments as to why this is > work that the DHC working group should be pursuing. > > If we don't standardize the leasequery capability, each vendor of > access concentrators and DHCP products that wish to use this > approach will then need to work together (possibly in some other > forum) to try to get their products to be compatible. Of course, > it may well be that we are the only folks who see this as a > useful capability, and so that may not be an issue at all. > > Thanks -- Kim > > ----------------------- Summary ----------------------- > > In case you haven't been following the email between Thomas > Narten and myself, he has been questioning the problem statement > of the leasequery draft. Ralph proposed a new problem statement, > but Thomas feels that this whole capability is questionable. > > You are invited to respond to Thomas' arguments, which I have > distilled as follows: > > 1. Doing anything in the DHC WG like supporting "access > control in router type devices" is out of scope for the working > group, and doesn't fit its current charter. > > 2. Access control in router type devices is not well enough > understood to be sure that: > > a) leasequery is the right solution. > > b) any DHC-based approach is the "right" approach to > solve this problem. > > 3. Until we are sure of 2(a), then we should not proceed with > this work (I believe that this statement is implicit in Thomas' > comments.) > > ----------------------- Background --------------------------- > > Here is Ralph's proposed problem statement: > > Router-type devices which want to enforce some level of access > control over which IP addresses are allowed on their links > need to maintain information concerning IP<-MAC/client-id > mappings. One way in which these devices can obtain > information about IP<-MAC/client-id bindings is through "DHCP > gleaning", in which the device extracts useful information > from DHCP messages exchanged between hosts and DHCP servers. > > However, these devices don't typically have stable storage > sufficient to keep this information over reloads. There may > be additional information that is useful to the device that > cannot be obtained through DHCP gleaning. The leasequery > request message described in this document allows a device to > obtain information about IP<-MAC/client-id bindings from a > DHCP server. This information may include currently active > bindings, bindings involving previously assigned addresses for > which the lease on the address has expired and static bindings > for devices that are otherwise configured and not using DHCP > for address assignment. > > Thomas' concerns center on the second paragraph above, and he says: > > Note, that above is pretty vague and doesn't say what > information the access device needs. It's hard to look at the > problem statement and say "yes, I understand the boundaries of > the problem" and then "and the solution seems like a good > match for the problem". > > Popping up a level, how is it even appropriate for the DHC WG > to be doing work on "access control in router type devices"? > One can argue that work of this broad a scope is well > out-of-scope for this WG (e.g., look at the recently approved > charter). I'm far from clear that work of this scope should > be done in DHC or that the problem is well enough understood > to conclude that DHC lease query is the right solution or that > any DHC-based solution is the right one. What about routers > wanting to do access control that don't use DHC, for instance? > > And note, I'm not raising these issue just to be a PITA. These > are questions that I expect that the IESG would ask if I > brought the document forward. Thus, I need to have reasonable > responses to those questions. Otherwise, I can predict the > likely outcome. > > My response to Thomas was: > > This approach to access control was developed by joint work > with the folks building our access concentrators and several > of us in the DHCP implementation group. They found that the > functionality delivered to actual users was of sufficient > value to those users to be worth the cost of engineering this > particular solution. We supported them in moving the > implementation forward. > > The solution was not based on the charter of the DHC working > group either then or now -- it was based on a rather pragmatic > approach to meeting the needs of users, which it has seemed to > do. In my view at least, it fits within spirit of the DHC WG > activities, and was a logical extension of the those > activities. > > It isn't a comprehensive approach to any sort of security (nor > was it designed to be such) -- it is a supporting piece of > technology to one limited form of access control. > > Thanks for your interest in the leasequery capability. > > Kim > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 08:50:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19227; Tue, 11 Mar 2003 08:50:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BE3uO31509; Tue, 11 Mar 2003 09:03:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BE2hO31475 for ; Tue, 11 Mar 2003 09:02:43 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19211 for ; Tue, 11 Mar 2003 08:48:43 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19845; Tue, 11 Mar 2003 06:50:51 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BDooP29186; Tue, 11 Mar 2003 14:50:50 +0100 (MET) Date: Tue, 11 Mar 2003 14:46:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: Ralph Droms Cc: dhcwg@ietf.org, ipng@playground.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [dhcwg] IPv6 prefix option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I saw this in 03: IAprefix-options: Options associated with this prefix but the document doesn't have an example of what this might be used for. Is there such an example? Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 08:54:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19352; Tue, 11 Mar 2003 08:54:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BE8BO32444; Tue, 11 Mar 2003 09:08:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BE7YO32277 for ; Tue, 11 Mar 2003 09:07:34 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19321 for ; Tue, 11 Mar 2003 08:53:36 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11526; Tue, 11 Mar 2003 06:55:41 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BDteP29466; Tue, 11 Mar 2003 14:55:40 +0100 (MET) Date: Tue, 11 Mar 2003 14:51:47 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] Leasequery: should it be standardized? To: "Bernie Volz (EUD)" Cc: "'Mark Stapp'" , Steve Gonczi , dhcwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I agree ... we don't want to restart this process. There's a lot of good > reasons why DHCP should be used - it is after all DHCP information. The > existing framework is fine regardless of whether the devices and > applications already knew dhcp. Bernie, As I understand Thomas' concerns part of the issue is that the draft talks about leasequery being used when there isn't a DHCP lease. Thus it's expanded to be able to ask questions about MAC/IP addresses in general. I think that distinction is quite important. Arguing that DHCP be used to query information about DHCP leases is one thing. Arguing that DHCP is the right protocol to use to query about MAC/IP address related information is a rather different thing. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 08:54:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19350; Tue, 11 Mar 2003 08:54:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BE86O32427; Tue, 11 Mar 2003 09:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BE7QO32095 for ; Tue, 11 Mar 2003 09:07:26 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19315 for ; Tue, 11 Mar 2003 08:53:28 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22626; Tue, 11 Mar 2003 06:55:32 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BDtVP29460; Tue, 11 Mar 2003 14:55:31 +0100 (MET) Date: Tue, 11 Mar 2003 14:51:38 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA To: Shankar Agarwal Cc: rbhibbs@pacbell.net, Dhcwg , "Chen, Weijing" In-Reply-To: "Your message with ID" <3E6D2F0A.89A93D07@net.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Right now we don't have a simple username password authentication > mechanism for DHCP and we have something very complicated which will not > be used in most common deployments. In most of the cases we are happy > with either cleartext user name password or may be MD5 encoded username > password authentication. If we put this within the current DHCP > framework then this will help in replacing the ppp in DSL and cabel > modem world where username password is used to pick up the profile of > the user. An alternative would be to figure out how PANA and DHC would work together in this case. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 09:23:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20329; Tue, 11 Mar 2003 09:23:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEbAO01433; Tue, 11 Mar 2003 09:37:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEaoO01252 for ; Tue, 11 Mar 2003 09:36:51 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20292 for ; Tue, 11 Mar 2003 09:22:51 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2BEOths015867; Tue, 11 Mar 2003 06:24:55 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA09453; Tue, 11 Mar 2003 14:24:54 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Erik Nordmark Cc: Ralph Droms , dhcwg@ietf.org, ipng@playground.sun.com Subject: Re: [dhcwg] IPv6 prefix option From: Ole Troan Date: Tue, 11 Mar 2003 14:24:54 +0000 In-Reply-To: (Erik Nordmark's message of "Tue, 11 Mar 2003 14:46:56 +0100 (CET)") Message-ID: <7t5heaa9e15.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Eric, > I saw this in 03: > IAprefix-options: Options associated with this prefix > but the document doesn't have an example of what this might be used for. > > Is there such an example? the last paragraph of section 10 gives an example. «The status of any operations involving this IA_PD Prefix option is indicated in a Status Code option in the IAprefix-options field.» /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 10:02:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21514; Tue, 11 Mar 2003 10:02:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFFSO04721; Tue, 11 Mar 2003 10:15:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFEsO04658 for ; Tue, 11 Mar 2003 10:14:54 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21449 for ; Tue, 11 Mar 2003 10:00:53 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.12.8/8.12.8) with ESMTP id h2BF2SJA006605; Tue, 11 Mar 2003 09:02:28 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.8/8.12.8) with ESMTP id h2BF2Shd025758; Tue, 11 Mar 2003 09:02:28 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 09:02:27 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Erik Nordmark'" Cc: "'Mark Stapp'" , Steve Gonczi , dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Tue, 11 Mar 2003 09:00:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7DE.FCADFE94" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2E7DE.FCADFE94 Content-Type: text/plain; charset="iso-8859-1" Erik: I don't disagree with your and Thomas' concerns, and I probably didn't read earlier dialogues carefully enough. Ralph and I spoke about this issue at Connectathon and I now understand the specific concern. I think DHCP should be used as it is today and the lease query may be used to extract that information. If the DHCP server has information regarding client reservations (or whatever you want to call fixed address assignments), there is no reason it can not report on those exactly as it would for any other lease. Whether the client uses DHCP to obtain its information or has static configuration is immaterial - the point is the that client *COULD* use DHCP and would get the information. In this case, as DHCP provides the client no indication that this is a reservation, I don't think lease query should either. So, I would be all for removing that indication from lease query. I also think that lease query should not recommend steps to add these reservations to the server if there is no intention of these clients ever using DHCP. But, I also feel that lease query should not prevent someone from doing this - it should simply be silent on the issue as this is a usage issue and not a standards issue. If a vendor wants to recommend doing this (and I can see reasons why they would), they could. - Bernie -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Tuesday, March 11, 2003 8:52 AM To: Bernie Volz (EUD) Cc: 'Mark Stapp'; Steve Gonczi; dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? > I agree ... we don't want to restart this process. There's a lot of good > reasons why DHCP should be used - it is after all DHCP information. The > existing framework is fine regardless of whether the devices and > applications already knew dhcp. Bernie, As I understand Thomas' concerns part of the issue is that the draft talks about leasequery being used when there isn't a DHCP lease. Thus it's expanded to be able to ask questions about MAC/IP addresses in general. I think that distinction is quite important. Arguing that DHCP be used to query information about DHCP leases is one thing. Arguing that DHCP is the right protocol to use to query about MAC/IP address related information is a rather different thing. Erik ------_=_NextPart_001_01C2E7DE.FCADFE94 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Leasequery: should it be standardized?

Erik:

I don't disagree with your and Thomas' concerns, and = I probably didn't read earlier dialogues carefully enough. Ralph and I = spoke about this issue at Connectathon and I now understand the = specific concern.

I think DHCP should be used as it is today and the = lease query may be used to extract that information. If the DHCP server = has information regarding client reservations (or whatever you want to = call fixed address assignments), there is no reason it can not report = on those exactly as it would for any other lease. Whether the client = uses DHCP to obtain its information or has static configuration is = immaterial - the point is the that client *COULD* use DHCP and would = get the information.

In this case, as DHCP provides the client no = indication that this is a reservation, I don't think lease query should = either. So, I would be all for removing that indication from lease = query.

I also think that lease query should not recommend = steps to add these reservations to the server if there is no intention = of these clients ever using DHCP. But, I also feel that lease query = should not prevent someone from doing this - it should simply be silent = on the issue as this is a usage issue and not a standards issue. If a = vendor wants to recommend doing this (and I can see reasons why they = would), they could.

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]<= /FONT>
Sent: Tuesday, March 11, 2003 8:52 AM
To: Bernie Volz (EUD)
Cc: 'Mark Stapp'; Steve Gonczi; = dhcwg@ietf.org
Subject: RE: [dhcwg] Leasequery: should it be = standardized?


> I agree ... we don't want to restart this = process. There's a lot of good
> reasons why DHCP should be used - it is after = all DHCP information. The
> existing framework is fine regardless of = whether the devices and
> applications already knew dhcp.

Bernie,

As I understand Thomas' concerns part of the issue is = that
the draft talks about leasequery being used when = there isn't a DHCP lease.
Thus it's expanded to be able to ask questions about = MAC/IP addresses
in general.

I think that distinction is quite important.
Arguing that DHCP be used to query information about = DHCP leases
is one thing.
Arguing that DHCP is the right protocol to use to = query about MAC/IP address
related information is a rather different = thing.

   Erik

------_=_NextPart_001_01C2E7DE.FCADFE94-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 10:38:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24066; Tue, 11 Mar 2003 10:38:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFq7O07404; Tue, 11 Mar 2003 10:52:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFpnO07377 for ; Tue, 11 Mar 2003 10:51:49 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24033 for ; Tue, 11 Mar 2003 10:37:48 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-377.cisco.com [10.82.225.121]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BFdrSd016731; Tue, 11 Mar 2003 10:39:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030311103147.00b220d8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Mar 2003 10:39:51 -0500 To: Erik Nordmark From: John Schnizlein Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA Cc: Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg , "Chen, Weijing" In-Reply-To: References: <"Your message with ID" <3E6D2F0A.89A93D07@net.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:51 AM 3/11/2003, Erik Nordmark wrote: >> Right now we don't have a simple username password authentication >> mechanism for DHCP and we have something very complicated which will not >> be used in most common deployments. In most of the cases we are happy >> with either cleartext user name password or may be MD5 encoded username >> password authentication. If we put this within the current DHCP >> framework then this will help in replacing the ppp in DSL and cabel >> modem world where username password is used to pick up the profile of >> the user. > >An alternative would be to figure out how PANA and DHC would work >together in this case. Another alternative is to follow the AAA that controls initial access at layer 2 (e.g. RADIUS authentication for IEEE 802.1X) with sending those RADIUS attributes to the DHCP server. This approach protects the access network and separates the functions of user authentication from address (and other parameter) configuration. The mechanism for interworking this way is in draft-ietf-dhc-agentopt-radius-02.txt. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 10:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24664; Tue, 11 Mar 2003 10:59:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGDAO09096; Tue, 11 Mar 2003 11:13:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGCMO09051 for ; Tue, 11 Mar 2003 11:12:22 -0500 Received: from mail.tgm.ac.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24588 for ; Tue, 11 Mar 2003 10:58:13 -0500 (EST) Received: from localhost (mail [127.0.0.1]) by mail.tgm.ac.at (Postfix) with ESMTP id 5B41F6E19F for ; Tue, 11 Mar 2003 17:00:19 +0100 (CET) Received: from mail ([127.0.0.1]) by localhost (mail [127.0.0.1:10026]) (amavisd-new) with ESMTP id 17787-07 for ; Tue, 11 Mar 2003 17:00:18 +0100 (CET) Received: from mail.tgm.ac.at (mail [127.0.0.1]) by mail (AvMailGate-2.0.1.6) id 18107-082572A5; Tue, 11 Mar 2003 17:00:17 +0100 Received: from tgm.ac.at (chello062178168036.13.14.vie.surfer.at [62.178.168.36]) by mail.tgm.ac.at (Postfix) with ESMTP id A411F6DF09 for ; Tue, 11 Mar 2003 17:00:17 +0100 (CET) Message-ID: <3E6E0804.70603@tgm.ac.at> Date: Tue, 11 Mar 2003 17:00:04 +0100 From: Markus Schabel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: dhcwg Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322806@trimail2> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322806@trimail2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.18.0.2; VDF: 6.18.0.13; host: tgm.ac.at) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Chen, Weijing wrote: > Questions for DHCP experts: > > 1) Does today's DHCP protocol specification support the client > authentication by user@domain and password? If not, is it possible to > extend it? > > > 2) Is there any DHCP server implementation of obtaining IP address > assignment through RADIUS protocol (i.e. IP address pool managed by RADIUS)? Maybe 802.1x is a solution for you? There you have an authentication on the switch-PORT (which could be done with a RADIUS-backend), and *after* you are authenticated the port is open and you can communicate with the network - you can only communicate with your DHCP *after* you passed the authentification-process. If your RADIUS uses LDAP as backend-database you probably can have some uid-password-mac-ip-mappings stored in the database, and DHCP is able (at least with a patch) to use LDAP as configuration-base. > -- ^ correct quotes are ^-- $ (note the *space*) regards -- \\\ ||| /// _\=/_ ( @ @ ) (o o) +--------oOOo-(_)-oOOo--------------------------oOOo-(_)-oOOo------+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | markus.schabel@tgm.ac.at Tel.: +43(1)33126/316 | | markus.schabel@members.fsf.org Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | | oOOo Yet Another Spam Trap: oOOo | | ( ) oOOo yast@tgm.ac.at ( ) oOOo | +--------\ (----( )--------------------------\ ( -----( )-----+ \_) ) / \_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 11:25:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25972; Tue, 11 Mar 2003 11:25:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGdFO11231; Tue, 11 Mar 2003 11:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGcmO11201 for ; Tue, 11 Mar 2003 11:38:48 -0500 Received: from howler.tri.sbc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25845 for ; Tue, 11 Mar 2003 11:24:46 -0500 (EST) Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.8/8.12.5) with ESMTP id h2BGM6Tq019967; Tue, 11 Mar 2003 10:22:06 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id h2BGM5D05147; Tue, 11 Mar 2003 10:22:05 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 10:22:05 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632280D@trimail2> From: "Chen, Weijing" To: "'John Schnizlein'" , Erik Nordmark Cc: Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg Subject: RE: [dhcwg] DHCP interconnected to RADIUS for AAA Date: Tue, 11 Mar 2003 10:21:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks you all for the reply. After review and discussion, we kind of lean toward over John's suggestion: .1x for authentication, DHCP for address allocation, and all tied together by RADIUS. Anyone can point me to the product actually implementing: client (network device, I think Windows XP is one), access device, RADIUS server and DHCP server as per John's draft? -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Tuesday, March 11, 2003 9:40 AM To: Erik Nordmark Cc: Shankar Agarwal; rbhibbs@pacbell.net; Dhcwg; Chen, Weijing Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA At 08:51 AM 3/11/2003, Erik Nordmark wrote: >> Right now we don't have a simple username password authentication >> mechanism for DHCP and we have something very complicated which will not >> be used in most common deployments. In most of the cases we are happy >> with either cleartext user name password or may be MD5 encoded username >> password authentication. If we put this within the current DHCP >> framework then this will help in replacing the ppp in DSL and cabel >> modem world where username password is used to pick up the profile of >> the user. > >An alternative would be to figure out how PANA and DHC would work >together in this case. Another alternative is to follow the AAA that controls initial access at layer 2 (e.g. RADIUS authentication for IEEE 802.1X) with sending those RADIUS attributes to the DHCP server. This approach protects the access network and separates the functions of user authentication from address (and other parameter) configuration. The mechanism for interworking this way is in draft-ietf-dhc-agentopt-radius-02.txt. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 11:34:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26410; Tue, 11 Mar 2003 11:34:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGm4O11716; Tue, 11 Mar 2003 11:48:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGeYO11347 for ; Tue, 11 Mar 2003 11:40:34 -0500 Received: from mx02.net.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26018 for ; Tue, 11 Mar 2003 11:26:31 -0500 (EST) Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx02.net.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id h2BGU0T28031 for ; Tue, 11 Mar 2003 08:30:00 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h2BGR8A29683 for ; Tue, 11 Mar 2003 08:27:08 -0800 (PST) Received: from net.com ([134.56.254.187]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA6DC8; Tue, 11 Mar 2003 08:29:09 -0800 Message-ID: <3E6E0DDF.260B2394@net.com> Date: Tue, 11 Mar 2003 08:25:03 -0800 From: "Prakash Jayaraman" Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.77 [en]C-NETv476west (Windows NT 5.0; U) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg , "Chen, Weijing" Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > Right now we don't have a simple username password authentication > > mechanism for DHCP and we have something very complicated which will not > > be used in most common deployments. In most of the cases we are happy > > with either cleartext user name password or may be MD5 encoded username > > password authentication. If we put this within the current DHCP > > framework then this will help in replacing the ppp in DSL and cabel > > modem world where username password is used to pick up the profile of > > the user. > > An alternative would be to figure out how PANA and DHC would work > together in this case. > Is there work currently in progress on such an alternative? (triggering a PANA transaction upon a DHCP message from the client or something similar). Would this be an appropriate forum to start a discussion? - prakash > > Erik > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 14:49:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07690; Tue, 11 Mar 2003 14:49:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BK34O27305; Tue, 11 Mar 2003 15:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BK06O27101 for ; Tue, 11 Mar 2003 15:00:06 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07510 for ; Tue, 11 Mar 2003 14:45:57 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BJm5Sc002251 for ; Tue, 11 Mar 2003 14:48:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06045 for ; Tue, 11 Mar 2003 14:48:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030311144153.03c0be70@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Mar 2003 14:48:04 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Jabber at dhc WG meeting in SF Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I would like to take advantage of the jabber text conferencing service as described below (thanks, Marshall, et al.) during the dhc WG meeting next week. I need to know two things: 1. Is anyone interested in remote participation through jabber? 2. Who will be willing to act as jabber scribe during the meeting? Please let me know as soon as possible if you would listen in on a jabber session from the WG meeting, so I can be sure to identify a scribe and get copies of presentations posted for remote viewing. - Ralph To: IETF-Announce:; Subject: Text Conferencing for the 56th IETF meeting in San Francisco Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 56th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ NOTE: the logging facility will not be active until later this week... ####### _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Mar 11 15:48:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11602; Tue, 11 Mar 2003 15:48:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BL2RO31501; Tue, 11 Mar 2003 16:02:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BL1CO31397 for ; Tue, 11 Mar 2003 16:01:12 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11499 for ; Tue, 11 Mar 2003 15:47:05 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11076; Tue, 11 Mar 2003 13:49:09 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BKn2P03971; Tue, 11 Mar 2003 21:49:03 +0100 (MET) Date: Tue, 11 Mar 2003 21:45:08 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA To: Prakash Jayaraman Cc: Erik Nordmark , Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg , "Chen, Weijing" In-Reply-To: "Your message with ID" <3E6E0DDF.260B2394@net.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Is there work currently in progress on such an alternative? (triggering a > PANA transaction upon a DHCP message from the client or something similar). > Would this be an appropriate forum to start a discussion? The simplest thing would be to have them operate independently e.g. PANA authentication first then DHC address assignment etc. That doesn't allow you to assign different addresses for different classes of authenticated devices though. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 12 08:12:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02502; Wed, 12 Mar 2003 08:12:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDQaO11060; Wed, 12 Mar 2003 08:26:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C8VZO23275 for ; Wed, 12 Mar 2003 03:31:35 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25950 for ; Wed, 12 Mar 2003 03:17:11 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B680C15210; Wed, 12 Mar 2003 17:20:23 +0900 (JST) Date: Wed, 12 Mar 2003 17:19:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5el5h5u0g.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> <7t5el5h5u0g.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Sat, 08 Mar 2003 23:16:31 +0000, >>>>> Ole Troan said: >> Since this is a MAY, the delegating router (i.e. server) MAY NOT send >> a Reply message, which will cause a bad effect (that the invalid >> prefix is going to be used). For the case of address assignment, this >> should be a minor issue, because this situation only happens when none >> of the events to issue a Confirm happen but the upstream router has >> somehow been swapped. > Rebind is only done for 10 seconds (using Confirms timers), then the > client goes back to Solicit state. Ah, okay, I missed the point. Then I'm fine with the current specification. It would still be helpful to explicitly note that Rebind only continues for 10 seconds, though. >> It would also be helpful to describe how the requesting should react >> to this event. > requesting router should go to Solicit state. I think this will be > made clearer in modified base spec/new PD revision where we'll use > NotOnLink rather than lifetimes = 0. Hmm, opt-prefix-delegation-03 still says: Rebind message If the delegating router cannot find a binding (...) the delegating router MAY send a Reply message to the requesting router containing the IA_PD with the lifetimes of the prefixes in the IA_PD set to zero. or are you talking about a change in a future revision? 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-admin@ietf.org Wed Mar 12 08:12:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02527; Wed, 12 Mar 2003 08:12:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDQjO11076; Wed, 12 Mar 2003 08:26:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C8XnO23356 for ; Wed, 12 Mar 2003 03:33:49 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25970 for ; Wed, 12 Mar 2003 03:19:26 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 65C6615210; Wed, 12 Mar 2003 17:22:38 +0900 (JST) Date: Wed, 12 Mar 2003 17:22:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 clarification draft and PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t58yvp5tht.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> <7t58yvp5tht.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Sat, 08 Mar 2003 23:27:42 +0000, >>>>> Ole Troan said: >> I know (and agree), but I'm saying the PD specification should be >> clear wherever a difference between address assignment and prefix >> delegation exist. We should be rather redundant than leave the >> difference ambiguous. At least please reconsider each issue in the >> interop draft and merge necessary changes from it. > agree. revision 3 of the PD draft should have most of the issues from > the interop document included. Okay, I'll check the changes in more detail. 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-admin@ietf.org Wed Mar 12 13:41:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15706; Wed, 12 Mar 2003 13:41:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIr1O03467; Wed, 12 Mar 2003 13:53:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CIp6O03422 for ; Wed, 12 Mar 2003 13:51:06 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15501 for ; Wed, 12 Mar 2003 13:36:31 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CIccvD021693 for ; Wed, 12 Mar 2003 13:38:39 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA25238 for ; Wed, 12 Mar 2003 13:38:38 -0500 (EST) Message-Id: <4.3.2.7.2.20030312133524.039dbd10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Mar 2003 13:38:38 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Jabber at dhc WG meeting in SF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've received expressions of interest from several people who would like to participate in the dhc WG meeting next week through jabber. That answers the question "Is anyone interested?" I still need an answer to the other question: "Who will be willing to act as jabber scribe during the meeting?" So, please let me know if you will volunteer to be the "jabber scribe"... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 12 15:58:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22141; Wed, 12 Mar 2003 15:58:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLCoO14619; Wed, 12 Mar 2003 16:12:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLBxO14561 for ; Wed, 12 Mar 2003 16:11:59 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21972 for ; Wed, 12 Mar 2003 15:57:19 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CKxSSc028671; Wed, 12 Mar 2003 15:59:28 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by goblet.cisco.com (Mirapoint) with ESMTP id ACU23154; Wed, 12 Mar 2003 15:59:25 -0500 (EST) Message-Id: <4.3.2.7.2.20030312155650.02372320@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Mar 2003 15:59:25 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Changes to create draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, Well, the failover draft *did* actually make it onto the IETF web site. Here is the final list of changes (once again): ------------------------------------------------------------------ Here is mail detailing the changes made to draft-ietf-dhc-failover-11.txt to yield draft-ietf-dhc-failover-12.txt. In most cases considerable changes were made to the indicated sections, so that it was not possible to say "this word changed to that word", but rather the entire section needs to be re-read to grasp the essence of the change. ------------------------------------------------------------------- During the last IETF in Atlanta, a discussion was held with several folks about problems in the DHCP failover protocol and its description. In attendance were: Scanner Luce scanner@nominum.com Bernie Volz Bernie.Volz@am1.ericsson.se Mark Stapp mjs@cisco.com Kim Kinnear kkinnear@cisco.com We primarily discussed issues encountered by Scanner during his implementation of the failover protocol, and first raised at a meeting with several people during the Summer 2002 IETF. Thanks to Bernie Volz for comments and additions to an earlier version of these notes. Some of his additions I've simply placed into the text, but I've left one comment explicit since we may want to discuss it further. The action plan for failover at this point is: (x) a. Circulate these notes to the DHCP list. (x) b. Accept comments. (x) c. Update the failover draft by the end of February. --> c-1. Circulate email concerning changes made. d. Consider whether we need another WG last call based on these changes. This email is step C-1. Changes made to the failover draft: ----------------------------------- While the discussion ranged over several topics, the action items boiled down to the following: 1. Connection establishment changes: a. There MUST be one endpoint failover relationship (i.e., between two servers). b. There SHOULD be one relationship per partner, but this is not a requirement. We determined there was little value in having the same two servers be involved in two relationships (in general). So, having one server be primary for some pools and secondary for others where the partner has opposite roles is really not necessary and makes little sense. Especially now that load balancing exists and the primary and secondary are almost equal (the primary just breaks ties). c. There SHOULD be only one port in use for failover traffic. d. The TCP connection from the secondary server to the primary server is dropped by the secondary server or is dropped by the primary server in the event that both servers end up connecting at the same time. We need a strategy to handle the case where two connections are done at the same time (primary -> secondary; secondary -> primary). The role is simply that the connection that the primary initiated is the one that is kept. So, the primary drops the connection it ACCEPTed from the secondary and the secondary drops the connection on which it CONNECTed to the primary. Modifications were made to implement these changes to: Definition of failover endpoint. Section 5.1.1 Failover endpoints Section 8. Connection Management Section 8.1 Connection granularity Section 8.2 Creating the TCP connection 2. Remove paragraph 4 from Section 7.1.3 (from the BNDUPD conflict section). This paragraph turns out to add as opposed to remove confusion. Modifications were made to implement this change by: Removing paragraph 4 from Section 7.1.3. 3. Consider adding pseudo-code for the MCLT logic (which Scanner has offered to contribute, since he felt this would be helpful.) I'll include anything I get in this regard. No modifications were made in this case, because I received no pseudo-code to add. Subsequent to sending this email the first time, I did receive some code from Scanner, and we are working to get it turned into pseudo-code which could be put into the draft. 4. Review sequence diagrams for accuracy. These were all reviewed, but no changes were made as no problems were found. If someone has problems with these sequence diagrams, please send me specific information about the problem, and I'll be glad to fix it. 5. The failover partners can run in two different modes -- time sync mode, or time skew mode. In time sync mode, still send the time, and the receiving server can be itself be in one of two modes -- time correction mode (to handle time drift) or time rejection mode (which will reject packets with a time that is "too wrong") in them. Bernie added: One point is that whichever mode one is in, one must allow some small drift in time when doing time based comparisons. For example, lease expirations may easily be off by 1 second just because of the time that elapsed between when a packet was sent and received (a very small fraction of time must elapse for this to potentially happen). I think that was more the issue that we need to make clear - time checks need to be somewhat soft rather than absolute? But I agree that servers may chose to require the time to be "in sync" or can chose to do time corrections. Note that we have found problems in not accommodating time skew; if the servers require the time to be in sync and continue running (but refuse to communicate) bad things sometimes happen (especially if the servers assume partner-down state). This can happen because step 6 in section 9.3.2 allows two actions. We may want to consider exactly what it means for the partner to be "down"; for example if the partner is up but a connection can not be established because the time-skew it out of range, then it may be better to have one server wait (typically the one that was down the longest?). Modifications were made to implement this change by changing: Section 5.10 Time synchronization between servers 6. The client-last-transaction-time should not be remembered if the packet is dropped due to the server being in the wrong failover state to respond to DHCP client packets. This was implicit in the previous versions of the draft, but not clearly stated. Modifications were made to implement this change by changing: Section 9.2 Server State Transitions 7. Contact information was changed, and some dates were updated to 2003. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 12 16:04:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22708; Wed, 12 Mar 2003 16:04:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLJ5O15262; Wed, 12 Mar 2003 16:19:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLIPO15230 for ; Wed, 12 Mar 2003 16:18:25 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22664 for ; Wed, 12 Mar 2003 16:03:46 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CL5tvD005002; Wed, 12 Mar 2003 16:05:55 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by goblet.cisco.com (Mirapoint) with ESMTP id ACU23304; Wed, 12 Mar 2003 16:05:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030312160053.023726e0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Mar 2003 16:05:52 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Leasequery draft update Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, I have updated the leasequery draft to try to address the issues raised by Thomas Narten concerning the problem statement and how it relates to the actual protcol extension described in the draft. I have changed the Abstract and the beginning of sections 1, 3, 4, and 5. The changes were restricted to the first few paragraphs of each numbered section. I mis-read the IETF deadline and so missed it. The draft is available, however, at: http://www.dhcp.org/draft-ietf-dhc-leasequery-05.txt I also made two minor editorial corrections to the draft found during the WG last call. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 12 18:44:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00237; Wed, 12 Mar 2003 18:44:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNvRO27290; Wed, 12 Mar 2003 18:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNuuO27261 for ; Wed, 12 Mar 2003 18:56:56 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00186 for ; Wed, 12 Mar 2003 18:42:14 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h2CNgLJD024087; Wed, 12 Mar 2003 16:42:21 -0700 (MST) Received: from 147.191.89.203 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 12 Mar 2003 16:42:09 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 12 Mar 2003 16:43:07 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637E7@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Bernie Volz (EUD)'" , "'Erik Nordmark'" cc: "'Mark Stapp'" , "Steve Gonczi" , dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Wed, 12 Mar 2003 16:42:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12711A5B488178-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8F0.FD745590" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2E8F0.FD745590 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit I *almost* agree with Bernie's email below. I agree that the Lease Query spec should not force a DHCP server operator to put reservations into the server, and not force the DHCP server to support such reservations, solely for making Lease Query work with such reservations. Although I agree in flexibility in reservation handling, I think we also need to ensure full multi-vendor interoperability for Lease Query clients (e.g. relay agents) and servers. That's the point of IETF standardization, right? A relay agent might choose (for simplicity of implementation) to use DHCP Lease Query as its sole external source of MAC/IP address information. Alternatively, a relay agent might choose to use DHCP Lease Query for DHCP lease information only, and use other mechanisms (e.g. local configuration, local routing state, remote MIB) for other MAC/IP address information. A specific, realistic example of another mechanism would be Reverse Path Forwarding. An access concentrator may be able to verify the source IP address of an upstream datagram by noting that the source IP address belongs to a particular IP subnet which has a particular nexthop IP gateway in the IP forwarding table, and the nexthop IP gateway maps to particular location information that can be discovered by DHCP Lease Query and/or by local configuration. We may have an interoperability problem if a relay agent expects only DHCP lease information in a Lease Query response, but gets other information (e.g. reservation information) in a response. This will lead to problems if the access concentrator expects to query other sources of information (e.g. a MIB) upon the failure of a Lease Query message -- and if the other source(s) would have responded with different IP/MAC address information than the (reservation in the) Lease Query response. -- Rich -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Tuesday, March 11, 2003 10:01 AM To: 'Erik Nordmark' Cc: 'Mark Stapp'; Steve Gonczi; dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? Erik: I don't disagree with your and Thomas' concerns, and I probably didn't read earlier dialogues carefully enough. Ralph and I spoke about this issue at Connectathon and I now understand the specific concern. I think DHCP should be used as it is today and the lease query may be used to extract that information. If the DHCP server has information regarding client reservations (or whatever you want to call fixed address assignments), there is no reason it can not report on those exactly as it would for any other lease. Whether the client uses DHCP to obtain its information or has static configuration is immaterial - the point is the that client *COULD* use DHCP and would get the information. In this case, as DHCP provides the client no indication that this is a reservation, I don't think lease query should either. So, I would be all for removing that indication from lease query. I also think that lease query should not recommend steps to add these reservations to the server if there is no intention of these clients ever using DHCP. But, I also feel that lease query should not prevent someone from doing this - it should simply be silent on the issue as this is a usage issue and not a standards issue. If a vendor wants to recommend doing this (and I can see reasons why they would), they could. - Bernie -----Original Message----- From: Erik Nordmark [ mailto:Erik.Nordmark@sun.com ] Sent: Tuesday, March 11, 2003 8:52 AM To: Bernie Volz (EUD) Cc: 'Mark Stapp'; Steve Gonczi; dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? > I agree ... we don't want to restart this process. There's a lot of good > reasons why DHCP should be used - it is after all DHCP information. The > existing framework is fine regardless of whether the devices and > applications already knew dhcp. Bernie, As I understand Thomas' concerns part of the issue is that the draft talks about leasequery being used when there isn't a DHCP lease. Thus it's expanded to be able to ask questions about MAC/IP addresses in general. I think that distinction is quite important. Arguing that DHCP be used to query information about DHCP leases is one thing. Arguing that DHCP is the right protocol to use to query about MAC/IP address related information is a rather different thing. Erik ------_=_NextPart_001_01C2E8F0.FD745590 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: [dhcwg] Leasequery: should it be standardized?
I *almost* agree with Bernie's email below.
 
I agree that the Lease Query spec should not force a DHCP server operator to put reservations into the server, and not force the DHCP server to support such reservations, solely for making Lease Query work with such reservations.
 
Although I agree in flexibility in reservation handling, I think we also need to ensure full multi-vendor interoperability for Lease Query clients (e.g. relay agents) and servers. That's the point of IETF standardization, right?
 
A relay agent might choose (for simplicity of implementation) to use DHCP Lease Query as its sole external source of MAC/IP address information. Alternatively, a relay agent might choose to use DHCP Lease Query for DHCP lease information only, and use other mechanisms (e.g. local configuration, local routing state, remote MIB) for other MAC/IP address information. A specific, realistic example of another mechanism would be Reverse Path Forwarding. An access concentrator may be able to verify the source IP address of an upstream datagram by noting that the source IP address belongs to a particular IP subnet which has a particular nexthop IP gateway in the IP forwarding table, and the nexthop IP gateway maps to particular location information that can be discovered by DHCP Lease Query and/or by local configuration.
 
We may have an interoperability problem if a relay agent expects only DHCP lease information in a Lease Query response, but gets other information (e.g. reservation information) in a response. This will lead to problems if the access concentrator expects to query other sources of information (e.g. a MIB) upon the failure of a Lease Query message -- and if the other source(s) would have responded with different IP/MAC address information than the (reservation in the) Lease Query response.
 
-- Rich
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, March 11, 2003 10:01 AM
To: 'Erik Nordmark'
Cc: 'Mark Stapp'; Steve Gonczi; dhcwg@ietf.org
Subject: RE: [dhcwg] Leasequery: should it be standardized?

Erik:

I don't disagree with your and Thomas' concerns, and I probably didn't read earlier dialogues carefully enough. Ralph and I spoke about this issue at Connectathon and I now understand the specific concern.

I think DHCP should be used as it is today and the lease query may be used to extract that information. If the DHCP server has information regarding client reservations (or whatever you want to call fixed address assignments), there is no reason it can not report on those exactly as it would for any other lease. Whether the client uses DHCP to obtain its information or has static configuration is immaterial - the point is the that client *COULD* use DHCP and would get the information.

In this case, as DHCP provides the client no indication that this is a reservation, I don't think lease query should either. So, I would be all for removing that indication from lease query.

I also think that lease query should not recommend steps to add these reservations to the server if there is no intention of these clients ever using DHCP. But, I also feel that lease query should not prevent someone from doing this - it should simply be silent on the issue as this is a usage issue and not a standards issue. If a vendor wants to recommend doing this (and I can see reasons why they would), they could.

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]
Sent: Tuesday, March 11, 2003 8:52 AM
To: Bernie Volz (EUD)
Cc: 'Mark Stapp'; Steve Gonczi; dhcwg@ietf.org
Subject: RE: [dhcwg] Leasequery: should it be standardized?


> I agree ... we don't want to restart this process. There's a lot of good
> reasons why DHCP should be used - it is after all DHCP information. The
> existing framework is fine regardless of whether the devices and
> applications already knew dhcp.

Bernie,

As I understand Thomas' concerns part of the issue is that
the draft talks about leasequery being used when there isn't a DHCP lease.
Thus it's expanded to be able to ask questions about MAC/IP addresses
in general.

I think that distinction is quite important.
Arguing that DHCP be used to query information about DHCP leases
is one thing.
Arguing that DHCP is the right protocol to use to query about MAC/IP address
related information is a rather different thing.

   Erik

------_=_NextPart_001_01C2E8F0.FD745590-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 13 09:15:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01138; Thu, 13 Mar 2003 09:15:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DETiO30727; Thu, 13 Mar 2003 09:29:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEQoO30599 for ; Thu, 13 Mar 2003 09:26:50 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01068 for ; Thu, 13 Mar 2003 09:11:50 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DEDwvD005139 for ; Thu, 13 Mar 2003 09:13:59 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00535 for ; Thu, 13 Mar 2003 09:13:58 -0500 (EST) Message-Id: <4.3.2.7.2.20030313090609.0204f490@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 09:13:58 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In the second paragraph of the introduction, at the top of page 2, there is an explanation of the motivation for this sub-option: The class of devices assumed in [2] is unlike the class of devices considered in [1], which perform a DNS lookup of the Kerberos Realm name to find the KDC server network address. [1] "DHCP Option for CableLabs Client Configuration draft-ietf-dhc- packetcable-06", IETF, February 2003. [2] "CableHome 1.0 Specification SP-CH1.0-I03-030124", CableLabs, January 2003, http://www.cablelabs.com/projects/cablehome/ specifications/. I looked in the CableHome specification [2], but couldn't find any text giving a more detailed explanation of the difference between the two kinds of clients. The KDC server address specification could use more detail, either by reference to the CableHome specification or in the KDC server address specification itself. Also, the "Security Considerations" section needs to either require the use of authenticated DHCP or explain why a rogue DHCP server can't compromise a CableHome client by sending the addresses of rogue KDC servers. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 13 13:08:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11008; Thu, 13 Mar 2003 13:08:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIMUO17742; Thu, 13 Mar 2003 13:22:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIL6O17617 for ; Thu, 13 Mar 2003 13:21:06 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10884 for ; Thu, 13 Mar 2003 13:06:03 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DI8ASc003882; Thu, 13 Mar 2003 13:08:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20781; Thu, 13 Mar 2003 13:08:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030313130543.00b675f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 13:08:10 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) Cc: Ole Troan , dhcwg@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: References: <7t5el5h5u0g.fsf@mrwint.cisco.com> <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> <7t5el5h5u0g.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I guess the next rev of the draft should change the text to indicate the use of NotOnLink. - Ralph At 05:19 PM 3/12/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Sat, 08 Mar 2003 23:16:31 +0000, > >>>>> Ole Troan said: > >[snip] > >> It would also be helpful to describe how the requesting should react > >> to this event. > > > requesting router should go to Solicit state. I think this will be > > made clearer in modified base spec/new PD revision where we'll use > > NotOnLink rather than lifetimes = 0. > >Hmm, opt-prefix-delegation-03 still says: > > Rebind message If the delegating router cannot find a binding >(...) > the delegating router MAY > send a Reply message to the requesting router > containing the IA_PD with the lifetimes of the > prefixes in the IA_PD set to zero. > >or are you talking about a change in a future revision? > > 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-admin@ietf.org Thu Mar 13 13:34:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12027; Thu, 13 Mar 2003 13:34:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIn8O19901; Thu, 13 Mar 2003 13:49:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DImnO19879 for ; Thu, 13 Mar 2003 13:48:49 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12005 for ; Thu, 13 Mar 2003 13:33:45 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DIZpvD028532; Thu, 13 Mar 2003 13:35:51 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA23379; Thu, 13 Mar 2003 13:35:50 -0500 (EST) Message-Id: <4.3.2.7.2.20030313133433.01fce288@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 13:35:50 -0500 To: Erik Nordmark From: Ralph Droms Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA Cc: Prakash Jayaraman , Erik Nordmark , Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg , "Chen, Weijing" In-Reply-To: References: <"Your message with ID" <3E6E0DDF.260B2394@net.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I don't understand how PANA can be used first - the requirements doc says: PANA does not perform any address assignment functions but MUST only be invoked after the client has a usable IP address (e.g., a link-local address in IPv6 or a DHCP-learned address in IPv4) - Ralph At 09:45 PM 3/11/2003 +0100, Erik Nordmark wrote: > > Is there work currently in progress on such an alternative? (triggering a > > PANA transaction upon a DHCP message from the client or something similar). > > Would this be an appropriate forum to start a discussion? > >The simplest thing would be to have them operate independently >e.g. PANA authentication first then DHC address assignment etc. >That doesn't allow you to assign different addresses for different classes >of authenticated devices though. > > Erik > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 13 14:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14473; Thu, 13 Mar 2003 14:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJpaO25081; Thu, 13 Mar 2003 14:51:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJoNO25001 for ; Thu, 13 Mar 2003 14:50:23 -0500 Received: from howler.tri.sbc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14386 for ; Thu, 13 Mar 2003 14:35:08 -0500 (EST) Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.8/8.12.5) with ESMTP id h2DJalTq006305; Thu, 13 Mar 2003 13:36:48 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id h2DJalr16723; Thu, 13 Mar 2003 13:36:47 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 13:36:46 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322812@trimail2> From: "Chen, Weijing" To: "'Ralph Droms'" , Erik Nordmark Cc: Prakash Jayaraman , Erik Nordmark , Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg Subject: RE: [dhcwg] DHCP interconnected to RADIUS for AAA Date: Thu, 13 Mar 2003 13:36:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Apparently I felt the same way after I read the PANA charter and requirements. I think this limitation (or assumption if you prefer) will keep PANA from deployed in real world. Regardless, we are investigating of 802.1x coupled with DHCP now. Weijing Chen -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, March 13, 2003 12:36 PM To: Erik Nordmark Cc: Prakash Jayaraman; Erik Nordmark; Shankar Agarwal; rbhibbs@pacbell.net; Dhcwg; Chen, Weijing Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA I don't understand how PANA can be used first - the requirements doc says: PANA does not perform any address assignment functions but MUST only be invoked after the client has a usable IP address (e.g., a link-local address in IPv6 or a DHCP-learned address in IPv4) - Ralph At 09:45 PM 3/11/2003 +0100, Erik Nordmark wrote: > > Is there work currently in progress on such an alternative? (triggering a > > PANA transaction upon a DHCP message from the client or something similar). > > Would this be an appropriate forum to start a discussion? > >The simplest thing would be to have them operate independently >e.g. PANA authentication first then DHC address assignment etc. >That doesn't allow you to assign different addresses for different classes >of authenticated devices though. > > Erik > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 13 14:48:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14994; Thu, 13 Mar 2003 14:48:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DK06O25618; Thu, 13 Mar 2003 15:00:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJxVO25553 for ; Thu, 13 Mar 2003 14:59:31 -0500 Received: from thumper.research.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14843 for ; Thu, 13 Mar 2003 14:44:25 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.8/8.12.1) with ESMTP id h2DJjFuG001284; Thu, 13 Mar 2003 14:45:16 -0500 (EST) Received: from localhost (ohba@tari-dhcp162.research.telcordia.com [207.3.232.162]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA11973; Thu, 13 Mar 2003 14:45:25 -0500 (EST) Date: Thu, 13 Mar 2003 14:45:14 -0500 To: Ralph Droms Cc: Erik Nordmark , Prakash Jayaraman , Shankar Agarwal , rbhibbs@pacbell.net, Dhcwg , "Chen, Weijing" Subject: Re: [dhcwg] DHCP interconnected to RADIUS for AAA Message-ID: <20030313194514.GJ781@catfish> References: <3E6E0DDF.260B2394@net.com> <4.3.2.7.2.20030313133433.01fce288@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030313133433.01fce288@funnel.cisco.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 56 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The latest version of PANA requirements draft says: (it missed the submission deadline, but it is available on http://www.toshiba.com/tari/pana/draft-ietf-pana-requirements-05.txt) 4.2. IP Address Assignment Providing address assignment functionality is outside the scope of PANA. PANA protocol design MAY require the PaC to configure an IP address before using this protocol. Allocating an IP address to unauthenticated PaCs may enable security vulnerabilities, such as IP address depletion attacks on the access network [SECTHREAT]. This threat may not be an issue for IPv6 because of the large address space, but it can effect IPv4 deployments. Such a threat can be mitigated by allowing the protocol to run without an IP address on the PaC (e.g., using unspecified source address), but this choice might limit the re-use of existing security mechanisms, and impose additional implementation complexity. This trade off should be taken into consideration in designing PANA. Yoshihiro Ohba On Thu, Mar 13, 2003 at 01:35:50PM -0500, Ralph Droms wrote: > I don't understand how PANA can be used first - the requirements doc says: > > PANA does not perform any address assignment functions > but MUST only be invoked after the client has a usable > IP address (e.g., a link-local address in IPv6 or a > DHCP-learned address in IPv4) > > - Ralph > > At 09:45 PM 3/11/2003 +0100, Erik Nordmark wrote: > >> Is there work currently in progress on such an alternative? (triggering a > >> PANA transaction upon a DHCP message from the client or something > >similar). > >> Would this be an appropriate forum to start a discussion? > > > >The simplest thing would be to have them operate independently > >e.g. PANA authentication first then DHC address assignment etc. > >That doesn't allow you to assign different addresses for different classes > >of authenticated devices though. > > > > Erik > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 14 05:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21262; Fri, 14 Mar 2003 05:37:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EAqFO32553; Fri, 14 Mar 2003 05:52:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EAnDO32455 for ; Fri, 14 Mar 2003 05:49:13 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21220; Fri, 14 Mar 2003 05:33:48 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2EAZvvD020338; Fri, 14 Mar 2003 05:35:57 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn4-121.cisco.com [10.21.80.121]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA19494; Fri, 14 Mar 2003 05:35:56 -0500 (EST) Message-Id: <4.3.2.7.2.20030314053515.03d774a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Mar 2003 05:35:55 -0500 To: agenda@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda for dhc WG meeting at IETF 56 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here is the latest agenda for the dhc WG meeting: DHC WG agenda - IETF 56 (Last revised 3/14/03 5:32) --------------------------- Administrivia; agenda bashing; WG progress report Ralph Droms 5 minutes Review of new charter; request for milestones Ralph Droms 10 minutes DHCP security review team report Barr Hibbs 10 minutes 'Securing DHCP with DNSSEC bourne public keys' Ted Lemon 15 minutes Authentication of relay agent options John Schnizlein 10 minutes VPN-ID option and sub-option Kim Kinnear 10 minutes DHCP server MIB Barr Hibbs 10 minutes Option code recovery Ralph Droms 5 minutes Option code extensions Bernie Volz 10 minutes Review of DHCP RFCs Barr Hibbs 10 minutes Failover protocol Kim Kinnear 10 minutes Lease query protocol Kim Kinnear 10 minutes http://www.dhcp.org/draft-ietf-dhc-leasequery-05.txt DHCPv6 status Ralph Droms 10 minutes DHCPv6 Interoperability test results DHCPv6 options ---------- Total 125 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 14 06:58:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23106; Fri, 14 Mar 2003 06:58:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ECD1O05421; Fri, 14 Mar 2003 07:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ECBWO05349 for ; Fri, 14 Mar 2003 07:11:32 -0500 Received: from palrel13.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23083 for ; Fri, 14 Mar 2003 06:56:07 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id 194861C00BC1 for ; Fri, 14 Mar 2003 03:58:12 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.11.1/8.9.3 SMKit7.02) with SMTP id h2EBvI502192 for ; Fri, 14 Mar 2003 17:27:18 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'DHCPWG'" Date: Fri, 14 Mar 2003 17:27:26 +0530 Message-ID: <002101c2ea20$e26a8540$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C2EA4E.FC22C140" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Subject: [dhcwg] Client Preferred Prefix option for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C2EA4E.FC22C140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the last IETF meeting, there were a discussion about the client preferred prefix option for DHCPv6 and i was asked to send the requirements for this option. The requirements for this option are: Scenario 1: The client's link has multiple prefixes of different scopes and the administrator policy on the server insists that the addresses need to be allocated on site-local prefixes only. The client will not be able to communicate with a node that belongs to a different site, as the server allocates only site-local addresses in IAs. Scenario 2: The client's link has two prefixes: site-local and global. The administrator policy insists that addresses need to be allocated on both the prefixes. All the nodes on a link will not communicate with external sites and thus all of them do not require global addresses. However, the server allocates addresses on both the prefixes. So, the client needs to send the release message to release the unwanted addresses, which requires extra transactions. Scenario 3: The node has used the stateless autoconf and learned about prefixes. Say, the link has two prefixes 3ffe::/64 and 3fff::/64 and the link has been subnetted to two sets with these prefixes. Now, suddenly the RAs say to use stateful autoconf. It depends up on the dhcpv6 configuration whether the node will get both the prefixes or not. It will be worser if the node using 3ffe::/64 has to renumber to 3fff::/64 unnecessarily, though both the prefixes are valid in the link. Scenario 4: In a highly secured environment where there is only a known IPv6 prefix by specific entities provided the knowledge of that prefix out of band not over a network. The entity will request this prefix as a DHCPv6 client and will provide secret security parameter to the DHCPv6 server. The server then provides a complete address for that prefix. The entity client now can use that address for communications with nodes that accept no other prefix on the network. The applications for this are special operations for entities like the Military, Law Enforcement, Fire Departments, and Doctors. To overcome the problems described in the above Scenarios, the client can specify its preferred prefixes to the server using Client Preferred Prefix option. Apart from the dumb devices like mobile phones, PDAs etc, there can be intelligent nodes which know their requirements and the necessary configuration. My draft concentrates on these kind of nodes. Anyhow, its just an option, the server can very well ignore it, if it not supporting it, thus doesn't bring any harm to the architecture. As i have not sumbitted the draft before March 3rd, it is not yet published, hence i am attaching the updated draft along with this mail. I will resubmit after March 17th. Please go through it and let me know your comments. ~ Vijay ------=_NextPart_000_0022_01C2EA4E.FC22C140 Content-Type: application/octet-stream; name="draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt" Content-Transfer-Encoding: quoted-printable =0A= Network Working Group A.K. Vijayabhaskar =0A= Internet-Draft Hewlett-Packard=0A= Expires: Sep 14, 2003 14 Mar 2003=0A= =0A= =0A= Client Preferred Prefix option for DHCPv6=0A= draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on September 14, 2003.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= This document describes the Client Preferred Prefix option by which=0A= the client can specify its preferred prefixes on which the addresses =0A= need to be allocated by the server.=0A= =0A= 1. Introduction=0A= =0A= Scenario 1: The client's link has multiple prefixes of different=0A= scopes and the administrator policy on the server insists that the =0A= addresses need to be allocated on site-local prefixes only. The =0A= client will not be able to communicate with a node that belongs to a =0A= different site, as the server allocates only site-local addresses in =0A= IAs.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires September 14, 2003 [Page 1]=0A= =0C=0A= Internet-Draft Client Preferred Prefix option for DHCPv6 Mar 2003=0A= =0A= Scenario 2: The client's link has two prefixes: site-local and global.=0A= The administrator policy insists that addresses need to be allocated =0A= on both the prefixes. All the nodes on a link will not communicate =0A= with external sites and thus all of them do not require global =0A= addresses. However, the server allocates addresses on both the =0A= prefixes. So, the client needs to send the release message to release=0A= the unwanted addresses, which requires extra transactions.=0A= =0A= Scenario 3: The node has used the stateless autoconf and learned =0A= about prefixes. Say, the link has two prefixes 3ffe::/64 and=0A= 3fff::/64 and the link has been subnetted to two sets with these=0A= prefixes. Now, suddenly the RAs say to use stateful autoconf. It=0A= depends up on the dhcpv6 configuration whether the node will get both=0A= the prefixes or not. It will be worser if the node using 3ffe::/64=0A= has to renumber to 3fff::/64 unnecessarily, though both the prefixes=0A= are valid in the link.=0A= =0A= Scenario 4: In a highly secured environment where there is only a=0A= known IPv6 prefix by specific entities provided the knowledge of that=0A= prefix out of band not over a network. The entity will request this =0A= prefix as a DHCPv6 client and will provide secret security parameter =0A= to the DHCPv6 server. The server then provides a complete address for =0A= that prefix. The entity client now can use that address for =0A= communications with nodes that accept no other prefix on the network. =0A= The applications for this are special operations for entities like =0A= the Military, Law Enforcement, Fire Departments, and Doctors.=0A= =0A= To overcome the problems described in the above Scenarios, the client =0A= can specify its preferred prefixes to the server using Client =0A= Preferred Prefix option.=0A= =0A= 2. Requirements=0A= =0A= The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,=0A= SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this=0A= document, are to be interpreted as described in RFC 2119 [2]=0A= =0A= 3. Terminology=0A= =0A= This document uses terminology specific to IPv6 and DHCPv6 as defined=0A= in section "Terminology" of the DHCP specification.=0A= =0A= 4. Client Preferred Prefix option=0A= =0A= Client Preferred Prefix option is used by the client to specify its =0A= preferred prefixes to the server.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires September 14, 2003 [Page 2]=0A= =0C=0A= Internet-Draft Client Preferred Prefix option for DHCPv6 Mar 2003=0A= =0A= The format of the Client Preferred Prefix option is as shown below:=0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | OPTION_CLIENT_PREF_PREFIX | option-len |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | prefix-len | |=0A= +-+-+-+-+-+-+-+-+-+ |=0A= | |=0A= | subnet prefix (n bytes) |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | prefix-len | |=0A= +-+-+-+-+-+-+-+-+-+ |=0A= | |=0A= | subnet prefix (n bytes) |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | ... |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= . .=0A= . client-pref-prefix-options .=0A= . .=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= option-code: OPTION_CLIENT_PREF_PREFIX (tbd)=0A= =0A= option-len: total length of the prefix-len and subnet prefix lists =0A= and its encapsulated options.=0A= =0A= prefix-len: prefix length of the subnet address.=0A= =0A= subnet prefix: 'n' bytes of subnet prefix, where 'n' is minimum =0A= number of bytes required to refer 'prefix-len' bits =0A= of the prefix.=0A= =0A= client-pref-prefix-options: options associated with Client =0A= Preferred Prefix option.=0A= =0A= 5. Server Behavior=0A= =0A= If the server policy doesn't support client preferred prefix option, =0A= then it can either send reply with OptionUnsupported in the =0A= encapsulated error code option in client preferred prefix option or =0A= allocate addresses based on its original policy. The server behavior =0A= SHOULD be configurable by the administrator.=0A= =0A= If the server policy supports client preferred prefix option and if =0A= this option contains one or more prefixes which are not valid for the =0A= client's link, then, the server MUST send the reply with error code =0A= NotOnLink. =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires September 14, 2003 [Page 3]=0A= =0C=0A= Internet-Draft Client Preferred Prefix option for DHCPv6 Mar 2003=0A= =0A= If the server policy supports client preferred prefix option and all =0A= the prefixes in this option are valid for the client's link, then the=0A= server MUST allocate addresses only on the prefixes specified in =0A= client preferred prefix option encapsulated in the IAs.=0A= =0A= 6. Client Behavior=0A= =0A= If the client has received OptionUnsupported error, it can either=0A= choose the next server to send request, till the server list gets=0A= exhausted or it can start the configuration exchange as specified in =0A= Section 18.1.1 of [1] without the client preferred prefix option.=0A= =0A= If the server list has exhausted then, it MUST start the configuration=0A= exchange as specified in Section 18.1.1 of [1] without the client =0A= preferred prefix option.=0A= =0A= If the client has received the addresses with the prefixes that were =0A= not specified in client preferred prefix option, it can release the =0A= unwanted addresses.=0A= =0A= 7. Appearance of these options=0A= =0A= Client Preferred Prefix option MUST occur only in Request and Reply=0A= messages. This option MUST occur in Reply messages only if it=0A= encapsulates the Error code option.=0A= =0A= Client Preferred Prefix option MUST occur only as an encapsulated =0A= option in the IA or IA_TA option.=0A= =0A= Client Preferred Prefix option MUST only have Error code option as the=0A= encapsulated option.=0A= =0A= =0A= =0A= 8. Security Considerations=0A= =0A= Since, this option can occur only in IA or IA_TA option, all the =0A= IA-relevant security considerations are applicable to this option too.=0A= =0A= To avoid attacks through this option, the DHCP client SHOULD use =0A= authenticated DHCP (see section "Authentication of DHCP messages" =0A= in the DHCPv6 specification [1]).=0A= =0A= 9. IANA Considerations=0A= =0A= IANA is requested to assign an option code to this option from the=0A= option-code space defined in section "DHCPv6 Options" of the DHCPv6=0A= specification [1].=0A= =0A= 10. Normative Reference=0A= =0A= [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.=0A= Droms (ed.), "Dynamic Host Configuration Protocol for IPv6=0A= (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November=0A= 2002.=0A= =0A= =0A= Vijayabhaskar A K Expires September 14, 2003 [Page 4]=0A= =0C=0A= Internet-Draft Client Preferred Prefix option for DHCPv6 Mar 2003=0A= =0A= =0A= 11. Informative Reference=0A= =0A= [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A= Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= Author's Address=0A= =0A= Vijayabhaskar A K=0A= Hewlett-Packard ESD-I=0A= 29, Cunningham Road=0A= Bangalore - 560052=0A= India=0A= =0A= Phone: +91-80-2053085=0A= E-Mail: vijayak@india.hp.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires September 14, 2003 [Page 5]=0A= =0C=0A= Internet-Draft Client Preferred Prefix option for DHCPv6 Mar 2003=0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society. Thanks to Jim Bound for his thorough review =0A= of the document.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires September 14, 2003 [Page 6]=0A= =0C=0A= ------=_NextPart_000_0022_01C2EA4E.FC22C140-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 14 07:29:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23718; Fri, 14 Mar 2003 07:29:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ECiSO07263; Fri, 14 Mar 2003 07:44:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ECh9O07217 for ; Fri, 14 Mar 2003 07:43:09 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23706 for ; Fri, 14 Mar 2003 07:27:43 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ECTqSc027574 for ; Fri, 14 Mar 2003 07:29:52 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA23439 for ; Fri, 14 Mar 2003 07:29:51 -0500 (EST) Message-Id: <4.3.2.7.2.20030314064203.00b77ec8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Mar 2003 06:51:21 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Prep for WG meeting, 3/17 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've published the most recent agenda to the WG mailing list; it's also available at http://www.dhcp.org/0303-agenda.txt Please review the new WG charter, http://www.ietf.org/html.charters/dhc-charter.html (also included below), before the WG meeting on Monday. We need to add milestones for current WG work items, which we'll discuss at the WG meeting. Also, please review the agenda and any applicable Internet-Drafts for discussion at the WG meeting. - Ralph ===== Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2003-02-16 Current Status: Active Working Group Chair(s): R. Droms Internet Area Director(s): Thomas Narten E. Nordmark Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www1.ietf.org/mailman/listinfo/dhcwg Description of Working Group The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The base protocol is documented in RFC2131 and RFC2132 (DHCP for IPv4) and RFCxxxx (DHCP for IPv6). Additional options are documented in subsequent RFCs. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * The DHC WG will address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC2131, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Complete or abandon work on DHCPv6 options that are currently work in progress: IPv6 Prefix Options for DHCPv6 DNS Configuration options for DHCPv6 Load Balancing for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 Client Preferred Prefix option for DHCPv6 A Guide to Implementing Stateless DHCPv6 Service DSTM Options for DHCPv6 DSTM Ports Option for DHCPv6 * Complete or abandon work on DHCP extensions and options that are currently work in progress: Failover protocol The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients DHCP Server MIB Considerations for the use of the Host Name option DHCP Lease Query DHCP Options for Internet Storage Name Service Dynamic Host Configuration Protocol (DHCP) Server MIB DHCP Option for Mobile IP Mobility Agents DHCP VPN Information Option KDC Server Address Sub-option The Authentication Suboption for the DHCP Relay Agent Option Link Selection sub-option for the Relay Agent Information Option VPN Identifier sub-option for the Relay Agent Information Option RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Done Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done Identify DHCPv4 authentication design team Done Identify DHCPv4 specification review design team Done Identify DHCPv4 relay agent message authentication design team Done WG Last Call on "DHCP Options for Internet Storage Name Service" Done WG Last Call on "DNS Configuration options for DHCPv6" Done WG Last Call on "NIS Configuration Options for DHCPv6" Done WG Last Call on "Time Configuration Options for DHCPv6" Done WG Last Call on "IPv6 Prefix Options for DHCPv6" Done WG Last Call on "Load Balancing for DHCPv6" 2003-02 Submit "DHCP Options for Internet Storage Name Service" to IESG 2003-02 Submit "DNS Configuration options for DHCPv6" to IESG 2003-02 Submit "NIS Configuration Options for DHCPv6" to IESG 2003-02 Submit "Time Configuration Options for DHCPv6" to IESG 2003-03 Submit "IPv6 Prefix Options for DHCPv6" to IESG 2003-03 Submit "Load Balancing for DHCPv6" to IESG 2003-06 DHCPv4 authentication design team report completed 2003-06 DHCPv4 specification review report completed 2003-06 Select DHCPv4 relay agent message authentication mechanism _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Mar 14 09:29:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26022; Fri, 14 Mar 2003 09:29:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EEhwO14455; Fri, 14 Mar 2003 09:43:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EEgTO14406 for ; Fri, 14 Mar 2003 09:42:29 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25973 for ; Fri, 14 Mar 2003 09:27:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2EETASc012411 for ; Fri, 14 Mar 2003 09:29:10 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00110 for ; Fri, 14 Mar 2003 09:29:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030314092429.038f4d18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Mar 2003 09:29:10 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] More about WG meeting in SF Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , If you plan to give an electronic presentation at the WG meeting in SF, please send me a copy that I can post at www.dhcp.org. A PDF version would be best, if possible. If you check http://www.dhcp.org/meetings.html, you'll see I've posted the slides I'll use at the meeting. The idea here is to make the presentations available to anyone participating in the jabber session from the WG meeting. And, I still haven't heard from anyone willing to volunteer to act as jabber scribe at the meeting. The jabber scribe will actually perform two functions - transcribe the meeting for remote participants, and - because the jabber session will be recorded - act as a source of notes for meeting minutes. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 17 11:13:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18438; Mon, 17 Mar 2003 11:13:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGTdO11769; Mon, 17 Mar 2003 11:29:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGRQO11695 for ; Mon, 17 Mar 2003 11:27:26 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18378 for ; Mon, 17 Mar 2003 11:10:28 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2HGCcSc015839; Mon, 17 Mar 2003 11:12:38 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn4-231.cisco.com [10.21.80.231]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01204; Mon, 17 Mar 2003 11:12:37 -0500 (EST) Message-Id: <4.3.2.7.2.20030317082118.03d43980@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Mar 2003 08:58:30 -0500 To: From: Ralph Droms Subject: Re: [dhcwg] Client Preferred Prefix option for DHCPv6 Cc: "'DHCPWG'" In-Reply-To: <002101c2ea20$e26a8540$38e62a0f@nt23056> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vijay - I have a couple of questions and comments about your requirements (in line)... - Ralph At 05:27 PM 3/14/2003 +0530, Vijayabhaskar A K wrote: >In the last IETF meeting, there were a discussion >about the client preferred prefix option for DHCPv6 >and i was asked to send the requirements for this >option. > >The requirements for this option are: > > > > Scenario 1: The client's link has multiple prefixes of different > scopes and the administrator policy on the server insists that the > addresses need to be allocated on site-local prefixes only. The > client will not be able to communicate with a node that belongs to a > different site, as the server allocates only site-local addresses in > IAs. If the DHPCv6 server policy is to assign addresses from site-local prefixes, what information would the client send to the server in the preferred prefix option? Even if the client expresses a preference for a global prefix, the server policy will override that preference and the client will receive only addresses from site-local prefixes. > Scenario 2: The client's link has two prefixes: site-local and global. > The administrator policy insists that addresses need to be allocated > on both the prefixes. All the nodes on a link will not communicate > with external sites and thus all of them do not require global > addresses. However, the server allocates addresses on both the > prefixes. So, the client needs to send the release message to release > the unwanted addresses, which requires extra transactions. Here, to, it seems the server policy would override any preferences from the client. > Scenario 3: The node has used the stateless autoconf and learned > about prefixes. Say, the link has two prefixes 3ffe::/64 and > 3fff::/64 and the link has been subnetted to two sets with these > prefixes. Now, suddenly the RAs say to use stateful autoconf. It > depends up on the dhcpv6 configuration whether the node will get both > the prefixes or not. It will be worser if the node using 3ffe::/64 > has to renumber to 3fff::/64 unnecessarily, though both the prefixes > are valid in the link. I think this scenario, too, represents a problem for cooordination of configuration between the prefixes advertised in RAs and the DHCPv6 server. It's up to the network admin to make sure that addresses assigned by the DHCPv6 server are coordinated with the advertised prefixes - there's no additional information for the client to supply to the server. > Scenario 4: In a highly secured environment where there is only a > known IPv6 prefix by specific entities provided the knowledge of that > prefix out of band not over a network. The entity will request this > prefix as a DHCPv6 client and will provide secret security parameter > to the DHCPv6 server. The server then provides a complete address for > that prefix. The entity client now can use that address for > communications with nodes that accept no other prefix on the network. > The applications for this are special operations for entities like > the Military, Law Enforcement, Fire Departments, and Doctors. For this scheme to work, I would think the client would have to know the network topology so it could decide what prefix or prefixes would be routable from the link to which the client is attached. Rather than giving that topology information to each client, it would be more efficient to program the topolgy information into the server and let the server decide which prefix or prefixes are appropriate. The client can still use an authenticated identification mechanism to convey its identity to the server for prefix selection. >~ Vijay > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 17 12:05:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20633; Mon, 17 Mar 2003 12:05:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHMDO16324; Mon, 17 Mar 2003 12:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHH7O16079 for ; Mon, 17 Mar 2003 12:17:07 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20414 for ; Mon, 17 Mar 2003 12:00:08 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HH2JvD026480 for ; Mon, 17 Mar 2003 12:02:20 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-507.cisco.com [10.21.97.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA05775 for ; Mon, 17 Mar 2003 12:02:18 -0500 (EST) Message-Id: <4.3.2.7.2.20030317120052.03cf70e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Mar 2003 12:02:19 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] jabber session from WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , For those of you trying to participate in a dhc WG jabber session ... apparently there is a problem with the IETF jabber server (name(s) of the server(s) not in DNS?), so, unless something changes, we won't have a jabber session running... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 17 12:58:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22799; Mon, 17 Mar 2003 12:58:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIELO21130; Mon, 17 Mar 2003 13:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIDFO21050 for ; Mon, 17 Mar 2003 13:13:16 -0500 Received: from palrel11.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22696 for ; Mon, 17 Mar 2003 12:56:14 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id 32A321C0136B; Mon, 17 Mar 2003 09:58:26 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.11.1/8.9.3 SMKit7.02) with SMTP id h2HHvlS22392; Mon, 17 Mar 2003 23:27:47 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Ralph Droms'" Cc: "'DHCPWG'" Subject: RE: [dhcwg] Client Preferred Prefix option for DHCPv6 Date: Mon, 17 Mar 2003 23:27:50 +0530 Message-ID: <003d01c2ecae$bafd9200$38e62a0f@nt23056> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <4.3.2.7.2.20030317082118.03d43980@funnel.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph, Thanks for your comments and see my reply inline. ~Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Monday, March 17, 2003 7:29 PM > To: vijayak@india.hp.com > Cc: 'DHCPWG' > Subject: Re: [dhcwg] Client Preferred Prefix option for DHCPv6 > > > Vijay - I have a couple of questions and comments about your > requirements > (in line)... > > - Ralph > > At 05:27 PM 3/14/2003 +0530, Vijayabhaskar A K wrote: > >In the last IETF meeting, there were a discussion > >about the client preferred prefix option for DHCPv6 > >and i was asked to send the requirements for this > >option. > > > >The requirements for this option are: > > > > > > > > Scenario 1: The client's link has multiple prefixes of different > > scopes and the administrator policy on the server > insists that the > > addresses need to be allocated on site-local prefixes only. The > > client will not be able to communicate with a node that > belongs to a > > different site, as the server allocates only site-local > addresses in > > IAs. > > If the DHPCv6 server policy is to assign addresses from site-local > prefixes, what information would the client send to the server > in the preferred prefix option? The client will send its preference by sending the prefix it wants in the client preferred prefix option, in this case, the site-local prefix. > Even if the client expresses a > preference for a global prefix, the server policy will override > that preference and the client will receive only addresses > from site-local prefixes. In this case, it is true. The client is asking for a prefix which cannot be provided by the server. But, not true for all the cases. Look at the next case. > > > > Scenario 2: The client's link has two prefixes: > site-local and global. > > The administrator policy insists that addresses need to > be allocated > > on both the prefixes. All the nodes on a link will not > communicate > > with external sites and thus all of them do not require global > > addresses. However, the server allocates addresses on both the > > prefixes. So, the client needs to send the release > message to release > > the unwanted addresses, which requires extra transactions. > > Here, to, it seems the server policy would override any preferences > from the client. Here, the client is not asking something which the server doesn't manage. It has a preference over one of those prefixes. That's it. Basically, when the server is not able to offer the address on the client requested prefix (or) server is not supporting this option, the server is going to do either one of the following : ignore the message as the whole (or) it can ignore this option and reply as if this option is not present in the client message. > > > Scenario 3: The node has used the stateless autoconf and learned > > about prefixes. Say, the link has two prefixes 3ffe::/64 and > > 3fff::/64 and the link has been subnetted to two sets with these > > prefixes. Now, suddenly the RAs say to use stateful autoconf. It > > depends up on the dhcpv6 configuration whether the node > will get both > > the prefixes or not. It will be worser if the node using > 3ffe::/64 > > has to renumber to 3fff::/64 unnecessarily, though both > the prefixes > > are valid in the link. > > I think this scenario, too, represents a problem for cooordination > of configuration between the prefixes advertised in RAs and the > DHCPv6 server. It's up to the network admin to make sure that > addresses assigned by the DHCPv6 server are coordinated with the > advertised prefixes - there's no additional information for the > client to supply to the server. The problem is not with the coordination of the configuration info, but with the allocation policy. Say, the policy is to allocate the addresses from one of the prefix, then the client may not get its prefered one. Here, it will be useful to have this option. > > > > Scenario 4: In a highly secured environment where there is only a > > known IPv6 prefix by specific entities provided the > knowledge of that > > prefix out of band not over a network. The entity will > request this > > prefix as a DHCPv6 client and will provide secret > security parameter > > to the DHCPv6 server. The server then provides a > complete address for > > that prefix. The entity client now can use that address for > > communications with nodes that accept no other prefix on > the network. > > The applications for this are special operations for > entities like > > the Military, Law Enforcement, Fire Departments, and Doctors. > > For this scheme to work, I would think the client would have to know > the network topology so it could decide what prefix or prefixes would > be routable from the link to which the client is attached. > Rather than > giving that topology information to each client, it would be > more efficient to program the topolgy information into the server > and let the server decide which prefix or prefixes are appropriate. > The client can still use an authenticated identification mechanism > to convey its identity to the server for prefix selection. Yes, of course, this option is for those clients which has an idea about the network topology and the prefixes in the links, which it has obtained through by some out of band mechanism. I think sending the authentication id along with the preferred prefix will be more easier and simpler than the server authenticating and deciding the prefixes for the the client with just the key information. Moreover, the client anyhow configured with the keys in some way out of band for these kind of highly secured environment, it can learn about the prefixes along with that. > > > > >~ Vijay > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 17 22:06:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14567; Mon, 17 Mar 2003 22:06:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I3MuO30262; Mon, 17 Mar 2003 22:22:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I3LgO30213 for ; Mon, 17 Mar 2003 22:21:42 -0500 Received: from smtp018.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14546 for ; Mon, 17 Mar 2003 22:04:29 -0500 (EST) Received: from adsl-64-169-91-177.dsl.snfc21.pacbell.net (HELO Barr1LKL501) (rbhibbs@pacbell.net@64.169.91.177 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Mar 2003 03:06:43 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Leasequery draft update Date: Mon, 17 Mar 2003 19:12:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20030312160053.023726e0@goblet.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit repeating what I said today during the working group meeting, I see no harm (and possible future value) if a DHCPv4 server can reply to a Lease Query message with whatever information it has at that moment about the current (and former) state of IP address leases. Since this effectively is the identical information that a relay agent could glean from the packet stream flowing between clients and servers, I see no reason not to permit a server to answer the Lease Query with information about previous IP address lease status, if it has maintained such information. I agree that the draft could be simplified by removing all consideration of "reservations." --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Mar 24 07:25:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12204; Mon, 24 Mar 2003 07:25:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCjNO29336; Mon, 24 Mar 2003 07:45:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OChXO29242 for ; Mon, 24 Mar 2003 07:43:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11614; Mon, 24 Mar 2003 07:23:15 -0500 (EST) Message-Id: <200303241223.HAA11614@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Mar 2003 07:23:15 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Client Preferred Prefix option for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt Pages : 6 Date : 2003-3-21 This document describes the Client Preferred Prefix option by which the client can specify its preferred prefixes on which the addresses need to be allocated by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-cliprefprefix-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-dhcpv6-opt-cliprefprefix-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: <2003-3-21154647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21154647.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 26 12:56:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05414; Wed, 26 Mar 2003 12:56:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIHKO18344; Wed, 26 Mar 2003 13:17:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIFBO18247 for ; Wed, 26 Mar 2003 13:15:11 -0500 Received: from palrel11.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05345 for ; Wed, 26 Mar 2003 12:53:47 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id D4FBF1C01947 for ; Wed, 26 Mar 2003 09:56:06 -0800 (PST) Received: (from ksenthil@localhost) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) id XAA25206 for dhcwg@ietf.org; Wed, 26 Mar 2003 23:25:27 +0530 (IST) From: SENTHIL KUMAR BALASUBRAMANIAN Message-Id: <200303261755.XAA25206@iconsrv5.india.hp.com> To: dhcwg@ietf.org Date: Wed, 26 Mar 2003 23:25:26 +0530 (IST) X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Proxy DHCP on port 4011 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I went through Intel's PXE specification and found that Proxy DHCP service on port 4011 is required. 1) Is it mandatory to have the Proxy DHCP service running on UDP port 4011. The reason i am asking this is because, we can actually implement the PXE related options alogn with normal DHCP itself. So why is that really required to have that service running on UDP port 4011. IBM AIX has separate daemon for Proxy DHCP (pxed) and Novell has (PDHCP.NLM). So i don't understand the reason why it has to be separate daemon. Is it just to not disturb the normal functionalites of DHCP.? We can always return the BOOT server types and IP addresses in the Vendor Specific Informaiton Option (Option 43) of normal DHCP reply itself. So Why should we have a separate daemon running for this service on port 4011. Appreciate your help in advance. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 26 14:55:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09839; Wed, 26 Mar 2003 14:55:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKGKO28591; Wed, 26 Mar 2003 15:16:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKFZO28532 for ; Wed, 26 Mar 2003 15:15:35 -0500 Received: from wesley.n3k.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09744 for ; Wed, 26 Mar 2003 14:54:07 -0500 (EST) Received: from wesley.n3k.de (localhost [127.0.0.1]) by wesley.n3k.de (8.11.4/8.11.4) with ESMTP id h2QL0wc01494 for ; Wed, 26 Mar 2003 21:00:58 GMT Received: from Server01.n3k.de (exchange.n3k.de [192.168.20.20]) by wesley.n3k.de (8.11.4/8.11.4) with ESMTP id h2QL0u701487; Wed, 26 Mar 2003 21:00:56 GMT Received: by Server01.n3k.de with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 20:56:26 +0100 Message-ID: <176C54EF9C7BBF4CB5FF9CB76DA9D33C10D173@Server01.n3k.de> From: Thomas Erhardt To: "'SENTHIL KUMAR BALASUBRAMANIAN'" , dhcwg@ietf.org Subject: AW: [dhcwg] Proxy DHCP on port 4011 Date: Wed, 26 Mar 2003 20:56:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QKFaO28533 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, it is not mandatory to run a DHCP Proxy Service. Most vendors provide information what options need to be configured on a DHCP server so it delivers all the PXE extensions options that the PXE client requires to operate correctly with the Boot Server they deliver. Depending on your environment you might not want to give the PXE administrators permission to modify your DHCP configuration or you don't want to reconfigure your DHCP server on behalf of the PXE admins all the time. Using a DHCP Proxy Service seperates "normal" DHCP administration and PXE administration. Regards, Thomas > -----Ursprüngliche Nachricht----- > Von: SENTHIL KUMAR BALASUBRAMANIAN [mailto:ksenthil@india.hp.com] > Gesendet: Mittwoch, 26. März 2003 18:55 > An: dhcwg@ietf.org > Betreff: [dhcwg] Proxy DHCP on port 4011 > > > I went through Intel's PXE specification and found that Proxy > DHCP service > on > port 4011 is required. > > 1) Is it mandatory to have the Proxy DHCP service running on > UDP port 4011. > The reason i am asking this is because, we can actually > implement the PXE > related options alogn with normal DHCP itself. So why is that really > required > to have that service running on UDP port 4011. > > IBM AIX has separate daemon for Proxy DHCP (pxed) and Novell has > (PDHCP.NLM). > So i don't understand the reason why it has to be separate daemon. > > Is it just to not disturb the normal functionalites of DHCP.? > > We can always return the BOOT server types and IP addresses > in the Vendor > Specific Informaiton Option (Option 43) of normal DHCP reply itself. > > So Why should we have a separate daemon running for this > service on port > 4011. > > Appreciate your help in advance. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Mar 26 14:56:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09938; Wed, 26 Mar 2003 14:56:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKH3O28675; Wed, 26 Mar 2003 15:17:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QKGpO28636 for ; Wed, 26 Mar 2003 15:16:51 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09817 for ; Wed, 26 Mar 2003 14:55:23 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2QJvhPh062362; Wed, 26 Mar 2003 14:57:43 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2QJvgTs079466; Wed, 26 Mar 2003 12:57:42 -0700 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.164]) by austin.ibm.com (8.12.6/8.12.6) with ESMTP id h2QJvfp2030968; Wed, 26 Mar 2003 13:57:42 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id NAA33982; Wed, 26 Mar 2003 13:57:41 -0600 Message-ID: <3E820634.27514A69@austin.ibm.com> Date: Wed, 26 Mar 2003 13:57:40 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: SENTHIL KUMAR BALASUBRAMANIAN CC: dhcwg@ietf.org Subject: Re: [dhcwg] Proxy DHCP on port 4011 References: <200303261755.XAA25206@iconsrv5.india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SENTHIL KUMAR BALASUBRAMANIAN wrote: > I went through Intel's PXE specification and found that Proxy DHCP service > on > port 4011 is required. > > 1) Is it mandatory to have the Proxy DHCP service running on UDP port 4011. > The reason i am asking this is because, we can actually implement the PXE > related options alogn with normal DHCP itself. So why is that really > required > to have that service running on UDP port 4011. It depends on which spec you read if it is 1.1 then you donot need PXE but if it is 2.1 then you need PXE. If you look at the protocol you will see in 2.x Client --> Discover --> DHCP server Client <-- OFFER ---- DHCP server ( which understand option 60) Client --> Request --> DHCP server Client <-- Ack --- DHCP server Client --> Request --> PXED (at port 4011) In the above the dhcp server is listening on the port 67 and pxed is also on the same machine as PXED so it listens on port 4011. Now pxed gives the required information to the client to discover BINLD server (boot server). Thanks Vasu > > > IBM AIX has separate daemon for Proxy DHCP (pxed) and Novell has > (PDHCP.NLM). > So i don't understand the reason why it has to be separate daemon. > > Is it just to not disturb the normal functionalites of DHCP.? > > We can always return the BOOT server types and IP addresses in the Vendor > Specific Informaiton Option (Option 43) of normal DHCP reply itself. > > So Why should we have a separate daemon running for this service on port > 4011. > > Appreciate your help in advance. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 27 06:33:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23694; Thu, 27 Mar 2003 06:33:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RBsvO09376; Thu, 27 Mar 2003 06:54:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7T2O20000 for ; Tue, 25 Mar 2003 02:29:02 -0500 Received: from vistb.2020media.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28694 for ; Tue, 25 Mar 2003 02:08:15 -0500 (EST) Received: from [212.212.6.42] (helo=2020scan.co.uk) by vistb.2020media.com with esmtp (Exim 4.05) id 18xiZq-0004Rx-00 for dhcwg@ietf.org; Tue, 25 Mar 2003 07:10:30 +0000 Received: from plesk-2.2020media.com [81.3.86.40] by 2020scan.co.uk [212.212.6.43] with SMTP (MDaemon.v3.5.7.R) for ; Tue, 25 Mar 2003 07:09:43 +0000 Received: (qmail 11515 invoked from network); 25 Mar 2003 07:09:41 -0000 Received: from unknown (HELO admin01) (202.62.84.103) by 81.3.86.41 with SMTP; 25 Mar 2003 07:09:41 -0000 From: "itsupport" To: Date: Tue, 25 Mar 2003 12:36:43 +0530 Message-ID: <000001c2f29d$29c63cc0$67543eca@admin01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C2F2CB.437FFF60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 81.3.86.40 X-Return-Path: itsupportindia@upaid.net X-MDaemon-Deliver-To: dhcwg@ietf.org X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18xiZq-0004Rx-00*72RDOQkijL6* Subject: [dhcwg] can you help me Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2F2CB.437FFF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear team , Hi I am nagaraju working as a system administrator I have one problem that is . I configured one dedicated dhcp server in that I have sufficient ip are there but frequently I get that ip conflict , my pool have 200 Ips and normally I used only 30 ips I have only 30 machine in my office. What is the problem for this and how to rectify this one . Can you give me the solution for this Regards, Nagaraju 3D"" ------=_NextPart_000_0001_01C2F2CB.437FFF60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear team = ,

 

        = ;    Hi   I am nagaraju working as a system administrator  I have one problem that = is  .   I configured one = dedicated dhcp server in that I have sufficient ip are there but frequently I get that ip = conflict  , my pool have 200 Ips and  normally I used only = 30 ips I have only 30 machine in my office.  What is the problem  for this and how to = rectify this one .

 

 Can  = you give me the solution for this

 

 

Regards,

Nagaraju

 


3D""
------=_NextPart_000_0001_01C2F2CB.437FFF60-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Mar 27 06:34:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23729; Thu, 27 Mar 2003 06:34:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RBu3O09425; Thu, 27 Mar 2003 06:56:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P7T2O19996 for ; Tue, 25 Mar 2003 02:29:02 -0500 Received: from vistb.2020media.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28693 for ; Tue, 25 Mar 2003 02:08:15 -0500 (EST) Received: from [212.212.6.42] (helo=2020scan.co.uk) by vistb.2020media.com with esmtp (Exim 4.05) id 18xiZq-0004Ry-00 for dhcwg@ietf.org; Tue, 25 Mar 2003 07:10:30 +0000 Received: from plesk-2.2020media.com [81.3.86.40] by 2020scan.co.uk [212.212.6.43] with SMTP (MDaemon.v3.5.7.R) for ; Tue, 25 Mar 2003 07:09:51 +0000 Received: (qmail 11520 invoked from network); 25 Mar 2003 07:09:56 -0000 Received: from unknown (HELO admin01) (202.62.84.103) by 81.3.86.41 with SMTP; 25 Mar 2003 07:09:56 -0000 From: "itsupport" To: Date: Tue, 25 Mar 2003 12:37:24 +0530 Message-ID: <000501c2f29d$3264cf90$67543eca@admin01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2F2CB.4C1D0B90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 81.3.86.40 X-Return-Path: itsupportindia@upaid.net X-MDaemon-Deliver-To: dhcwg@ietf.org X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18xiZq-0004Ry-00*72RDOQkijL6* Subject: [dhcwg] can you help me Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2F2CB.4C1D0B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear team , Hi I am nagaraju working as a system administrator I have one problem that is . I configured one dedicated dhcp server in that I have sufficient ip are there but frequently I get that ip conflict , my pool have 200 Ips and normally I used only 30 ips I have only 30 machine in my office. What is the problem for this and how to rectify this one . Can you give me the solution for this Regards, Nagaraju 3D"" ------=_NextPart_000_0006_01C2F2CB.4C1D0B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear team = ,

 

        = ;    Hi   I am nagaraju working as a system administrator  I have one problem that = is  .   I configured one = dedicated dhcp server in that I have sufficient ip are there but frequently I get that ip = conflict  , my pool have 200 Ips and  normally I used only = 30 ips I have only 30 machine in my office.  What is the problem  for this and how to = rectify this one .

 

 Can  = you give me the solution for this

 

 

Regards,

Nagaraju

 


3D""
------=_NextPart_000_0006_01C2F2CB.4C1D0B90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg